Oracle Cloud Infrastructure-Dokumentation

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

Bietet zusätzliche Informationen und Hinweise zur Verwendung von vom Kunden verwalteten Schlüsseln 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

Nachdem Sie zu vom Kunden verwalteten Schlüsseln gewechselt haben, können einige Datenbankvorgänge betroffen sein, wenn der Schlüssel nicht erreichbar ist.

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

  • Es gibt eine 2-stündige Nachfrist, bei der die Datenbank hochgefahren und gestartet bleibt.

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

  • Wenn Autonomous Data Guard bei Verwendung von Oracle Cloud Infrastructure Vault aktiviert ist, können Sie während oder nach der 2-stündigen Nachfrist manuell versuchen, einen Failover-Vorgang auszuführen. Das automatische Failover von Autonomous Data Guard wird nicht ausgelöst, wenn Sie vom Kunden verwaltete 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 ist, 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.

Vorsicht bei der Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln, wenn der Masterschlüssel deaktiviert oder gelöscht wird

Nachdem Sie zu vom Kunden verwalteten Schlüsseln gewechselt haben, können einige Datenbankvorgänge betroffen sein, wenn der Masterschlüssel deaktiviert oder gelöscht wird.

  • Beim Deaktivieren/Löschen von Schlüsselvorgängen mit einem der folgenden Masterverschlüsselungsschlüssel Status:

    Schlüssel-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 versetzt wurde. 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 15-Minuten-Intervallen).

  • Wenn Sie den von Autonomous Database verwendeten Oracle Cloud Infrastructure Vault-Schlüssel 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, wechselt die Datenbank automatisch in den Status "Verfügbar".

  • Wenn Sie den Masterschlüssel löschen, können Sie die Schlüsselhistorie in der Oracle Cloud Infrastructure-Konsole prüfen, um die Schlüssel zu finden, 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 weiterhin verfügbar ist, können Sie die Datenbank bis zu dem Zeitpunkt wiederherstellen, zu dem die Datenbank diesen Schlüssel verwendet hat, oder Sie können aus einem Backup klonen, um eine neue Datenbank mit diesem Zeitstempel zu erstellen.

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

Vorsicht bei der Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln - Historie und Backups

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

  • Es wird empfohlen, einen neuen Schlüssel zu erstellen, der in den letzten 60 Tagen nicht für die Rotation verwendet wurde, und diesen Schlüssel 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, entweder einen neuen Schlüssel für jeden Rotationsvorgang des Masterverschlüsselungsschlüssels zu erstellen oder einen Schlüssel anzugeben, 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 aus einem Backup wiederherstellen können, falls ein vom Kunden verwalteter Masterverschlüsselungsschlüssel deaktiviert oder gelöscht wird.

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

Hinweise für vom Kunden verwaltete Schlüssel 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 zu vom Kunden verwalteten Schlüsseln wechseln. Wenn Sie vom Kunden verwaltete Schlüssel verwenden, können Sie 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 Standbydatenbank mit vom Kunden verwalteten Schlüsseln verwenden:

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

    Vom Kunden verwaltete Verschlüsselungsschlüssel werden nur mit einer einzelnen regionsübergreifenden Autonomous Data Guard-Standbydatenbank unterstützt. Mehrere regionsübergreifende Standbydatenbanken werden nicht unterstützt, da Oracle Cloud Infrastructure Vault nur die Replikation in einer Remoteregion unterstützt.

  • Die Primär- und die Standbydatenbank verwenden denselben Schlüssel. Bei einem Switchover oder Failover auf die Standbydatenbank können Sie weiterhin denselben Schlüssel 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 verwalteten Schlüsseln zu von Oracle verwalteten Schlüsseln wechseln, wird die Änderung in der Standbydatenbank widergespiegelt.

  • Wenn Oracle Cloud Infrastructure Vault nicht erreichbar ist, erfolgt eine 2-stündige Nachfrist, bevor die Datenbank in den Status INACCESSIBLE übergeht. Sie können ein Failover während oder nach dieser 2-Stunden-Nachfrist ausführen.

  • Wenn Sie den Oracle Cloud Infrastructure-Masterverschlüsselungsschlüssel, den Ihre Autonomous Database mit vom Kunden verwalteten Schlüsseln verwendet, deaktivieren oder löschen, während Autonomous Data Guard aktiviert ist, führt Autonomous Data Guard keinen automatischen Failover aus.

  • Vom Kunden verwaltete Verschlüsselungsschlüsseln werden mit 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.