Oracle Cloud Infrastructure-Dokumentation

Hinweise zur Verwendung vom Kunden verwalteter Schlüssel mit Autonomous Database

Enthält zusätzliche Informationen und Hinweise zur Verwendung vom Kunden verwalteter Schlüssel mit Autonomous Database

Übergeordnetes Thema: Verschlüsselungsschlüssel in Autonomous Database verwalten

Achtung für vom Kunden verwaltete Verschlüsselungsschlüssel, wenn der Schlüssel nicht erreichbar ist

Wenn Sie zu vom Kunden verwalteten Schlüsseln gewechselt haben, sind einige Datenbankvorgänge möglicherweise davon betroffen, wenn der Schlüssel nicht erreichbar ist.

Wenn die Datenbank aus einem bestimmten Grund, wie z.B. aus einem Netzwerkausfall, nicht auf Ihren Schlüssel zugreifen kann, verarbeitet Autonomous Database den Ausfall wie folgt:

  • Die Datenbank bleibt während einer 2-Stunden-Frist hochgefahren.

  • Wenn der Schlüssel am Ende der 2-stündigen Verlängerungsfrist nicht erreichbar ist, wird der Lebenszyklusstatus der Datenbank auf Unzugänglich gesetzt. In diesem Status werden vorhandene Verbindungen gelöscht, und neue Verbindungen sind nicht zulässig.

  • Wenn Autonomous Data Guard bei der Verwendung von Oracle Cloud Infrastructure Vault während oder nach der 2-stündigen Verlängerungsfrist aktiviert ist, können Sie manuell versuchen, einen Failover-Vorgang auszuführen. Der automatische Failover von Autonomous Data Guard wird nicht ausgelöst, wenn Sie benutzerdefinierte Verschlüsselungsschlüssel verwenden und Oracle Cloud Infrastructure Vault nicht erreichbar ist.

    Hinweis

    Nur Oracle Cloud Infrastructure Vault wird mit Autonomous Data Guard unterstützt.

  • Wenn Autonomous Database gestoppt wurde, können Sie die Datenbank nicht starten, wenn die Schlüssel nicht erreichbar sind.

    In diesem Fall wird in der Arbeitsanforderung, die angezeigt wird, wenn Sie auf der Seite "Autonomous Database-Details" in der Oracle Cloud Infrastructure-Konsole auf die Registerkarte Arbeitsanforderungen klicken, Folgendes angezeigt: 

    The Vault service is not accessible. 
Your Autonomous Database could not be started. Please contact Oracle Support.

Warnhinweise zur Verwendung vom Kunden verwalteter Verschlüsselungsschlüssel, wenn der Master-Schlüssel deaktiviert oder gelöscht wurde

Wenn Sie zu vom Kunden verwalteten Schlüsseln gewechselt haben, sind einige Datenbankvorgänge möglicherweise davon betroffen, wenn der Masterschlüssel deaktiviert oder gelöscht wird.

  • Bei Vorgängen zum Deaktivieren/Löschen von Schlüsseln, wenn der Status des Masterverschlüsselungsschlüssels einen der folgenden Werte aufweist:

    Key Vault Schlüsselstatus
    Oracle Cloud Infrastructure (OCI) Vault
    • DISABLING
    • DISABLED
    • DELETING
    • DELETED
    • SCHEDULING_DELETION
    • PENDING_DELETION
    AWS Key Management System (KMS)
    • Disabled
    • PendingDeletion
    Azure Key Vault
    • DISABLED
    • DELETED
    Oracle Key Vault (OKV)
    • COMPROMISED
    • DEACTIVATED
    • DESTROYED

    Die Datenbank wird Nicht zugänglich, nachdem der Lebenszyklusstatus des Schlüssels in einen dieser Status wechselt. Wenn sich der Schlüssel in einem dieser Status befindet, löscht Autonomous Database vorhandene Verbindungen und lässt keine neuen Verbindungen zu.

    Der Zugriff auf die Datenbank kann nach den Schlüsselvorgängen bis zu 15 Minuten dauern (Autonomous Database prüft den Schlüsselprovider in Intervallen von 15 Minuten).

  • Wenn Sie den von Autonomous Database verwendeten Oracle Cloud Infrastructure Vault deaktivieren oder löschen, während Autonomous Data Guard aktiviert ist, führt Autonomous Data Guard keinen automatischen Failover aus.

    Hinweis

    Nur Oracle Cloud Infrastructure Vault wird mit Autonomous Data Guard unterstützt.

  • Wenn Sie einen deaktivierten Schlüssel aktivieren, geht die Datenbank automatisch in den verfügbaren Status übergehen.

  • Wenn Sie den Master-Schlüssel löschen, können Sie in der Schlüsselhistorie in der Oracle Cloud Infrastructure-Konsole nach den Schlüsseln suchen, die für die Datenbank verwendet wurden. In der Historie wird der Schlüsselname zusammen mit einem Aktivierungszeitstempel angezeigt. Wenn einer der älteren Schlüssel aus der Historienliste noch verfügbar ist, können Sie die Datenbank auf den Zeitpunkt wiederherstellen, zu dem die Datenbank diesen Schlüssel verwendet hat, oder Sie können sie von einem Backup klonen, um eine neue Datenbank mit diesem Zeitstempel zu erstellen.

Weitere Informationen finden Sie unter Historie für kundenverwaltete Verschlüsselungsschlüssel in Autonomous Database anzeigen.

Warnung bei der Verwendung der Historie vom Kunden verwalteter Verschlüsselungsschlüssel und von Backups

Nachdem Sie zu vom Kunden verwalteten Schlüsseln gewechselt haben, können einige Datenbankvorgänge davon betroffen sein, wenn der Masterschlüssel rotiert, deaktiviert oder gelöscht wird und Sie keinen gültigen Schlüssel haben, um Ihre Daten aus einem zuvor gespeicherten Backup oder aus einem Klon wiederherzustellen.

  • Es wird empfohlen, einen neuen Schlüssel zu erstellen, der in den letzten 60 Tagen nicht für die Rotation verwendet wurde, und diesen für die Rotation zu verwenden. Dadurch wird sichergestellt, dass Sie zu einem Backup zurückkehren können, wenn der aktuelle Schlüssel gelöscht oder deaktiviert wird.

  • Wenn Sie mehrere Verschlüsselungsschlüsselrotationen innerhalb von 60 Tagen ausführen, wird empfohlen, dass Sie entweder einen neuen Schlüssel für jede Rotation des Masterverschlüsselungsschlüssels erstellen oder einen Schlüssel angeben, der in den letzten 60 Tagen nicht verwendet wurde. Auf diese Weise können Sie mindestens einen Schlüssel speichern, mit dem Sie Ihre Daten von einem Backup wiederherstellen können, wenn ein vom Kunden verwalteter Master-Verschlüsselungsschlüssel deaktiviert oder gelöscht wird.

Weitere Informationen finden Sie unter Historie für kundenverwaltete Verschlüsselungsschlüssel in Autonomous Database anzeigen.

Hinweise zu vom Kunden verwalteten Schlüsseln in OCI Vault mit Autonomous Data Guard

Autonomous Data Guard wird unterstützt, wenn vom Kunden verwaltete Schlüssel mit dem Schlüsselprovider Oracle Cloud Infrastructure Vault verwendet werden.

Hinweis

Wenn Sie von Oracle verwaltete Schlüssel verwenden, können Sie nur von der Primärdatenbank aus zu vom Kunden verwalteten Schlüsseln wechseln. Wenn Sie vom Kunden verwaltete Schlüssel verwenden, können Sie auch nur Schlüssel rotieren oder von der Primärdatenbank zu von Oracle verwalteten Schlüsseln wechseln. Die Option Verschlüsselungsschlüssel verwalten unter Weitere Aktionen ist in einer Standbydatenbank deaktiviert.

Beachten Sie Folgendes, wenn Sie Autonomous Data Guard mit einer Standby-Datenbank mit vom Kunden verwalteten Schlüsseln verwenden:

  • Damit eine Remotestandbydatenbank denselben Masterverschlüsselungsschlüssel wie die Primärdatenbank verwenden kann, muss der Masterverschlüsselungsschlüssel in der Remoteregion repliziert werden.

    Kundenverwaltete Verschlüsselungsschlüssel werden nur bei einer einzelnen regionsübergreifenden Autonomous Data Guard-Standby unterstützt. Mehrere regionsübergreifende Standbys werden nicht unterstützt, da Oracle Cloud Infrastructure Vault die Replikation nur in einer Remoteregion unterstützt.

  • Die Primärdatenbank und die Standbydatenbank verwenden denselben Schlüssel. Im Falle eines Switchovers oder Failovers zur Standby-Datenbank können Sie denselben Schlüssel weiter verwenden.

  • Wenn Sie den vom Kunden verwalteten Schlüssel in der Primärdatenbank rotieren, wird dies in der Standbydatenbank widergespiegelt.

  • Wenn Sie von vom Kunden zu von Oracle verwalteten Schlüsseln wechseln, wird die Änderung in der Standbydatenbank wiedergegeben.

  • Wenn Oracle Cloud Infrastructure Vault nicht erreichbar ist, gibt es eine 2-stündige Verlängerungsfrist, bevor die Datenbank in den Status INACCESSIBLE wechselt. Sie können ein Failover während oder nach dieser 2-stündigen Kulanzfrist durchführen.

  • Wenn Sie den von Autonomous Database verwendeten Oracle Cloud Infrastructure-Masterverschlüsselungsschlüssel mit vom Kunden verwalteten Schlüsseln deaktivieren oder löschen, während Autonomous Data Guard aktiviert ist, wird kein automatischer Failover ausgeführt.

  • Vom Kunden verwaltete Verschlüsselungsschlüssel werden bei mandantenübergreifendem Autonomous Data Guard nicht unterstützt.

In den folgenden Themen finden Sie weitere Informationen:

Hinweise für vom Kunden verwaltete Verschlüsselungsschlüssel mit aktualisierbaren Klonen

Listet Einschränkungen und Hinweise zur Verwendung von vom Kunden verwalteten Schlüsseln mit aktualisierbaren Klonen auf.

Hinweis

Die Option zur Verwendung von vom Kunden verwalteten Schlüsseln mit einem aktualisierbaren Klon ist nur verfügbar, wenn die Quelldatenbank das ECPU-Compute-Modell verwendet.

Aktualisierbarer Klon mit Quelle für gleiche Region mit vom Kunden verwalteten Verschlüsselungsschlüsseln - Hinweise

Autonomous Database unterstützt die Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln mit einem aktualisierbaren Klon in derselben Region wie folgt:

  • Wenn die Quelldatenbank vom Kunden verwaltete Schlüssel verwendet, können Sie einen oder mehrere lokale (dieselbe Region) aktualisierbare Klone erstellen. Die aktualisierbaren Klone verwenden dieselben vom Kunden verwalteten Schlüssel wie die Quelldatenbank und unterstützen nicht die Option, einen anderen Schlüssel unabhängig voneinander auszuwählen oder den Schlüsseltyp auf aktualisierbaren Klonen zu ändern.

  • Alle vom Kunden verwalteten Schlüsselprovider werden für einen aktualisierbaren Klon derselben Region unterstützt, einschließlich: Oracle Cloud Infrastructure Vault, Microsoft Azure Key Vault, Amazon Web Services (AWS) Key Management Service (KMS) und Oracle Key Vault (OKV).

    Weitere Informationen finden Sie unter Masterverschlüsselungsschlüssel in Autonomous Database verwalten.

  • Sie können den Schlüsseltyp ändern oder den Schlüssel in der Quelldatenbank rotieren, wenn die Quelldatenbank über mindestens einen lokalen aktualisierbaren Klon verfügt. In diesem Fall verwendet ein aktualisierbarer Klon den vorhandenen alten Schlüssel, nachdem die Quelldatenbank auf einen anderen Schlüsseltyp umgeschaltet oder sein Schlüssel rotiert wurde. Nachdem ein aktualisierbarer Klon aktualisiert wurde, wechselt der aktualisierbare Klon zur Verwendung des neuen Quellschlüsseltyps oder zur Verwendung des rotierten Schlüssels.

  • Wenn Sie einen aktualisierbaren Klon aus einer Quelle mit einem vom Kunden verwalteten Schlüssel bereitstellen, müssen die dynamischen Gruppen und Policys den aktualisierbaren Klon abdecken, damit der aktualisierbare Klon auch auf den Schlüssel zugreifen kann. Wenn die dynamischen Gruppen und Policys den aktualisierbaren Klon nicht enthalten, verläuft das Provisioning nicht erfolgreich. Wenn die Quelle bereits über einen aktualisierbaren Klon verfügt und von von von Oracle verwalteten Schlüsseln zu vom Kunden verwalteten Schlüsseln wechselt, ist der Switch nicht erfolgreich, wenn die dynamischen Gruppen und Policys den aktualisierbaren Klon nicht enthalten.

    Weitere Informationen finden Sie unter Voraussetzungen für das Erstellen eines aktualisierbaren Klons.

Weitere Informationen finden Sie unter Aktualisierbaren Klon für eine Autonomous Database-Instanz erstellen.

Regionsübergreifender aktualisierbarer Klon mit Quelle mit vom Kunden verwalteten Verschlüsselungsschlüsseln - Hinweise

Autonomous Database unterstützt die Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln mit einem regionsübergreifenden aktualisierbaren Klon wie folgt:

  • Wenn die Quelldatenbank vom Kunden verwaltete Schlüssel verwendet, können Sie einen regionsübergreifenden aktualisierbaren Klon erstellen. Der aktualisierbare Klon verwendet dieselben vom Kunden verwalteten Schlüssel wie die Quelldatenbank und unterstützt nicht die Option, einen anderen Schlüssel unabhängig auszuwählen oder den Schlüsseltyp im aktualisierbaren Klon zu ändern.

    In diesem Fall wird nur OCI Vault für den regionsübergreifenden aktualisierbaren Klon unterstützt, und der Quellschlüssel muss in der Remoteregion repliziert werden.

  • Der vom Kunden verwaltete Schlüsselprovider mit einem regionsübergreifenden aktualisierbaren Klon lautet: Oracle Cloud Infrastructure Vault.

    Weitere Informationen finden Sie unter Masterverschlüsselungsschlüssel in Autonomous Database verwalten.

  • Wenn ein regionsübergreifender aktualisierbarer Klon einen vom Kunden verwalteten Schlüssel verwendet, müssen die dynamischen Gruppen und Policys den aktualisierbaren Klon abdecken. Wenn die dynamischen Gruppen und Policys den aktualisierbaren Klon nicht enthalten, verläuft das Provisioning nicht erfolgreich. Wenn die Quelle bereits über einen aktualisierbaren Klon verfügt und von von von Oracle verwalteten Schlüsseln zu vom Kunden verwalteten Schlüsseln wechselt, ist der Switch nicht erfolgreich, wenn die dynamischen Gruppen und Policys den aktualisierbaren Klon nicht enthalten.

    Weitere Informationen finden Sie unter Voraussetzungen für das Erstellen eines aktualisierbaren Klons.

Weitere Informationen finden Sie unter Mandantenübergreifenden oder regionsübergreifenden aktualisierbaren Klon erstellen.

Mandantenübergreifender aktualisierbarer Klon mit Quelle anhand von vom Kunden verwalteten Verschlüsselungsschlüsseln - Hinweise

Autonomous Database unterstützt nicht die Verwendung von Vom Kunden verwalteten Verschlüsselungsschlüsseln mit einem mandantenübergreifenden aktualisierbaren Klon.

Weitere Informationen finden Sie unter Mandantenübergreifenden oder regionsübergreifenden aktualisierbaren Klon erstellen.

Quelldatenbank mit einem aktualisierbaren Klon mit vom Kunden verwalteten Verschlüsselungsschlüsseln wiederherstellen - Hinweise

Wenn eine Quelldatenbank über einen aktualisierbaren Klon verfügt und die Quelldatenbank aus Backups wiederhergestellt wird, verwendet die Quelldatenbank den Schlüssel, der zum Zeitpunkt der Wiederherstellung der Quelldatenbank verwendet wurde.

Berücksichtigen Sie in diesem Fall die folgenden Fälle:

  • Wenn der aktualisierbare Klon verzögert war und der Aktualisierungspunkt vor dem Restore Point lag, d.h. der aktualisierbare Klon hatte Daten, die älter waren als die wiederhergestellte Quelldatenbank, verwendet er nach der nächsten Aktualisierung denselben Schlüssel wie die Quelldatenbank. (Bei einer Aktualisierung wird der aktualisierbare Klon aus der Quelldatenbank neu erstellt.)

  • Wenn der Aktualisierungspunkt des aktualisierbaren Klons nach dem Wiederherstellungspunkt lag, was bedeutet, dass der aktualisierbare Klon aktuellere Daten als die wiederhergestellte Quelldatenbank hatte, wird der aktualisierbare Klon automatisch neu erstellt, wenn er denselben Zeitpunkt mit Aktualisierungen erreicht. Zu diesem Zeitpunkt sollte der gleiche Schlüssel wie die Quelle angezeigt werden.

Weitere Informationen finden Sie unter Autonomous Database wiederherstellen und wiederherstellen.

Nicht verbundener aktualisierbarer Klon mit vom Kunden verwalteten Verschlüsselungsschlüsseln - Hinweise

Wenn ein aktualisierbarer Klon mit einer Quelldatenbank, die vom Kunden verwaltete Schlüssel verwendet, getrennt ist, kann sich der aktualisierbare Klon erneut mit der Quelldatenbank verbinden. Wenn sich der Schlüssel in der Quelldatenbank ändert, während der aktualisierbare Klon von der Quelle getrennt wird, wechselt der aktualisierbare Klon, um den neuen Schlüssel zu verwenden, wenn der aktualisierbare Klon erneut verbunden und aktualisiert wird.

Hinweise für vom Kunden verwaltete Schlüssel mit Vault im Remotemandanten

Um vom Kunden verwaltete Masterverschlüsselungsschlüssel mit einem Vault in einem Remotemandanten zu verwenden, beachten Sie Folgendes:

Wenn Sie vom Kunden verwaltete Masterverschlüsselungsschlüssel mit einem Vault in einem Remotemandanten verwenden, müssen sich der Vault und die Autonomous Database-Instanz in derselben Region befinden. Um den Mandanten zu ändern, klicken Sie auf der Anmeldeseite auf Mandanten ändern. Nachdem Sie den Mandanten geändert haben, müssen Sie dieselbe Region sowohl für den Vault als auch für die Autonomous Database-Instanz auswählen.