Key Protect-Integration

Die von Ihnen in IBM Cloud® Databases gespeicherten Daten werden standardmäßig unter Verwendung zufällig generierter Schlüssel verschlüsselt. Um die Verschlüsselungsschlüssel zu kontrollieren, können Sie Ihren eigenen Schlüssel (BYOK) über IBM Key Protect mitbringen und einen Ihrer eigenen Schlüssel zur Verschlüsselung Ihrer Datenbanken und Sicherungen verwenden.

Dieses Dokument behandelt die Integration von Key Protect mit Cloud Databases, zu denen Databases for PostgreSQL, Databases for MongoDB, Databases for Redis, Databases for Elasticsearch, IBM Cloud® Databases for MySQL, Messages for RabbitMQ, Databases for EnterpriseDB und Databases for etcd.

Zum Starten benötigen Sie Key Protect, das in Ihrem IBM Cloud-Konto eingerichtet sein muss.

Schlüssel in Key Protect erstellen oder hinzufügen

Rufen Sie Ihre Instanz von Key Protect auf und generieren Sie einen Schlüssel oder geben Sie ihn ein.

Erteilung der Dienstberechtigung in der Benutzeroberfläche

Autorisieren Sie Key Protect für die Verwendung mit Cloud Databases-Bereitstellungen:

Öffnen Sie das IBM Cloud-Dashboard.
Klicken Sie in der Menüleiste auf Verwalten-> Zugriff (IAM).
Klicken Sie in der Seitennavigation auf Autorisierungen.
Klicken Sie auf Erstellen.
Wählen Sie im Menü Quellenservice den Service der Implementierung aus. Beispielsweise Databases for PostgreSQL oder Messages for RabbitMQ.
Wählen Sie im Menü Quelldienstressourcen die Option Alle Ressourcen.
Wählen Sie im Menü Zielservice die Option Key Protect aus.
Wählen Sie oder behalten Sie den Standardwert Konto als Ressourcengruppe für den Zieldienst bei
Wählen Sie im Menü für die Instanz-ID des Zielservice die Serviceinstanzen aus, die autorisiert werden sollen.
Aktivieren Sie die Rolle Leseberechtigter.
Wenn Sie 'Bring Your Own Key' (BYOK) für Sicherungen verwenden möchten, wählen Sie das Feld Delegierung von Autorisierungen aktivieren im Abschnitt Abhängige Services autorisieren aus.
Klicken Sie auf Autorisieren.

Wenn die Serviceautorisierung nicht vorhanden ist, bevor Ihre Bereitstellung mit einem Schlüssel eingerichtet wird, schlägt die Einrichtung fehl.

Key Protect-Schlüssel verwenden

Nachdem Sie Ihren Cloud Databases-Bereitstellungen die Berechtigung zum Verwenden Ihrer Schlüssel erteilt haben, geben Sie den Schlüsselnamen oder CRN jeweils an, wenn Sie Bereitstellungen einrichten. Die Bereitstellung verwendet Ihren Verschlüsselungsschlüssel, um Ihre Daten zu verschlüsseln.

Verwendung der Taste " Key Protect " in der Benutzeroberfläche

Wenn die Einrichtung über die Katalogseite erfolgt, wählen Sie die Key Protect-Instanz und den Schlüssel aus den Dropdown-Menüs aus.

Verwendung des Key Protect in der CLI

Verwenden Sie in der Befehlszeilenschnittstelle (CLI) den Parameter disk_encryption_key_crn im JSON-Objekt des Parameters.

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-NAME> standard us-south \
-p \ '{
  "disk_encryption_key_crn": "crn:v1:<...>:key:<id>"
}'

Der Key Protect muss durch seine vollständige CRN identifiziert werden, nicht nur durch seine ID. Ein Key Protect-CRN hat das Format crn:v1:<...>:key:<id>.

Verwendung des Key Protect in der API

Verwenden Sie in der API den Parameter disk_encryption_key im Hauptteil der Anforderung.

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "my-instance",
    "target": "blue-us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-x-standard",
    "disk_encryption_key_crn": "crn:v1:<...>:key:<id>"
  }'

Der Key Protect muss durch seine vollständige CRN identifiziert werden, nicht nur durch seine ID. Ein Key Protect-CRN hat das Format crn:v1:<...>:key:<id>.

Schlüsselrotation

Key Protect bietet die manuelle und die automatische Schlüsselrotation und die Schlüsselrotation wird von Cloud Databases-Bereitstellungen unterstützt. Wenn Sie einen Schlüssel turnusmäßig wechseln, leitet der Prozess eine Task zum Synchronisieren des KMS-Status ein und Ihre Bereitstellung wird mit dem neuen Schlüssel neu verschlüsselt. Die Aufgabe wird auf der Seite Tasks in der Übersicht Ihrer Bereitstellung angezeigt, und die zugehörigen Key Protect und Cloud-Datenbases-Ereignisse werden an Activity Tracker gesendet.

Weitere Informationen finden Sie unter Manuelles oder automatisches Drehen.

Bereitstellung löschen

Wenn Sie eine Bereitstellung löschen, die mit einem Key Protect-Schlüssel geschützt ist, bleibt die Bereitstellung während des Zeitraums der vorläufigen Löschung (bis zu neun Tage) für den Schlüssel registriert. Um den Schlüssel in der Soft-Löschperiode zu löschen, erzwingen Sie das Löschen des Schlüssels. Nach dem Ende des Zeitraums für die vorläufige Löschung kann der Schlüssel ohne Erzwingen gelöscht werden. Um festzustellen, wann Sie den Schlüssel löschen können, prüfen Sie die Zuordnung zwischen dem Schlüssel und Ihrer Bereitstellung.

Kryptografisches Vernichten

Kryptografisches Vernichten ist eine zerstörerische Aktion. Wenn der Schlüssel gelöscht ist, können Ihre Daten nicht mehr wiederhergestellt werden.

Key Protect ermöglicht Ihnen, die erzwungene Löschung (Force Delete) eines Schlüssels auszuführen, der von IBM Cloud®-Services, einschließlich Ihren Cloud Databases-Bereitstellungen, verwendet wird. Diese Aktion wird als kryptografisches Vernichten von Daten (Crypto-Shredding) bezeichnet. Durch das Löschen eines in Ihrer Bereitstellung verwendeten Schlüssels werden die Platten gesperrt, die Ihre Daten enthalten, und die Bereitstellung wird inaktiviert. Sie können weiterhin auf die Benutzerschnittstelle und einige Metadaten zugreifen, wie z. B. Sicherheitseinstellungen in der Benutzerschnittstelle, der CLI und der API, Sie können jedoch nicht auf eine der Datenbanken oder auf die in ihnen enthaltenen Daten zugreifen. Die Löschung des Schlüssels wird an Activity Tracker als kms.secrets.delete gesendet.

Eigenen Schlüssel für Sicherungen verwenden

Wenn Sie Key Protectverwenden, können Sie bei der Bereitstellung einer Datenbank auch einen Schlüssel zum Verschlüsseln der Cloud Object Storage -Platte festlegen, die die Sicherungen Ihrer Implementierung enthält.

BYOK für Backups ist nur in den US-Regionen us-south und us-east und eu-de verfügbar.

Nur die Schlüssel in den Bereichen " us-south und " eu-de sind für regionale Ausfälle geeignet. Um sicherzustellen, dass Ihre Backups auch bei einem Ausfall einer Region verfügbar sind, müssen Sie einen Schlüssel aus ' us-south oder ' eu-de verwenden, unabhängig davon, wo sich Ihr Einsatz befindet.

Delegierungsautorisierung erteilen

Damit Ihre Bereitstellung den Key Protect verwenden kann, müssen Sie bei der Erteilung der Dienstberechtigungen die Delegierung der Berechtigung aktivieren. Wenn die Delegierungsautorisierung nicht vorhanden ist, bevor Ihre Bereitstellung mit einem Schlüssel eingerichtet wird, schlägt die Einrichtung fehl.

Verwendung des Schlüssels bei der Bereitstellung in der CLI

Nachdem die entsprechende Autorisierung und Delegierung erteilt wurde, geben Sie den Schlüsselnamen oder CRN bei der Einrichtung einer Bereitstellung jeweils an.

Verwenden Sie in der Befehlszeilenschnittstelle (CLI) den Parameter backup_encryption_key_crn im JSON-Objekt des Parameters.

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-NAME> standard us-south \
-p \ '{
  "backup_encryption_key_crn": "crn:v1:<...>:key:<id>"
}'

Verwendung des Schlüssels bei der Bereitstellung in der API

Verwenden Sie in der API den Parameter backup_encryption_key_crn im Hauptteil der Anforderung.

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "my-instance",
    "target": "blue-us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-x-standard",
    "backup_encryption_key_crn": "crn:v1:<...>:key:<id>"
  }'

Nachdem Sie die Delegierung aktiviert und Ihre Bereitstellung durchgeführt haben, werden in IAM zwei Einträge in Ihren Berechtigungen angezeigt. Der eine Eintrag ist der Eintrag für die Bereitstellung, die ihren Status als Delegierender auflistet. Er ist vom Benutzer erstellt ('User Created').

Beispiel Delegator Key Protect Autorisierung
Rolle	Quelle	Ziel	Typ
Delegierender der Autorisierung, Leseberechtigter	`<cloud-databases>` Service	Key Protect-Service	Benutzerdefiniert

Der andere Eintrag ist für den Cloud Object Storage-Bucket für die zugehörigen Sicherungen, wobei die Bereitstellung der Initiator ist.

Beispiel für die Key Protect für Cloud Object Storage aus Cloud Databases
Rolle	Quelle	Ziel	Typ
Leseberechtigter	Cloud Object Storage-Service	Key Protect-Service	Erstellt von `<cloud-databases-crn>`

Schlüssel entfernen

IAM/Key Protect hindert Sie nicht daran, die Richtlinie zwischen dem Schlüssel und Cloud Object Storage (das zweite Beispiel) zu entfernen; falls Sie dies jedoch tun, könnte es sein, dass Ihre Sicherungen nicht mehr wiederherstellbar sind. Um dies zu vermeiden, wird die Cloud Object Storage-Richtlinie, die die Cloud Databases-Fähigkeit zum Verwenden des Schlüssels für Cloud Object Storage reguliert, erneut erstellt (und Ihre Bereitstellung wird somit weiterhin gesichert), falls Sie sie löschen.

Gehen Sie beim Entfernen von Schlüsseln und Berechtigungen vorsichtig vor. Falls Sie über mehrere Bereitstellungen verfügen, die dieselben Schlüssel verwenden, kann es sein, dass Sicherungen für alle diese Bereitstellungen versehentlich zerstört werden, falls die Delegierungsautorisierung widerrufen wird. Verwenden Sie nach Möglichkeit nicht denselben Schlüssel für die Backups mehrerer Bereitstellungen.

Wenn Sie die Sicherungen vernichten (shred) möchten, können Sie den Schlüssel löschen. Cloud Object Storage stellt sicher, dass der Speicher nicht lesbar und nicht beschreibbar ist. Bei allen anderen Bereitstellungen, die denselben Schlüssel für Sicherungen verwenden, kommt es jedoch zu weiteren Sicherungsfehlern.

Wenn es erforderlich ist, dass Sie denselben Schlüssel für die Sicherungen mehrerer Bereitstellungen verwenden, können beim Entfernen von Schlüsseln und Autorisierungen folgende Nebeneffekte auftreten.

Wenn Sie nur die Cloud Object Storage-Autorisierung (wie in Tabelle 2 gezeigt) löschen, ist nicht nur die als Ersteller angezeigte Bereitstellung betroffen, sondern es sind auch alle Bereitstellungen betroffen, die denselben Schlüssel verwenden. Bei diesen Bereitstellungen können temporäre Sicherungsausfälle auftreten, bis die Richtlinie automatisch erneut erstellt wurde. Außer dem Fehlen von Sicherungen sollten keine langfristigen Auswirkungen auftreten.
Wenn Sie nur die von Ihnen erstellte Delegator-Berechtigung für Cloud Databases löschen (wie in Tabelle 1 zu sehen), geht nichts sofort kaputt, weil die zweite Berechtigung noch vorhanden ist. Sollte die Cloud Object Storage-Autorisierung jedoch entfernt werden, kann sie nicht erneut erstellt werden, und dies kann dazu führen, dass die Bereitstellungen, die denselben Schlüssel verwenden, keine Sicherungen mehr ausführen können.
Wenn Sie die Cloud Object Storage-Autorisierung UND die Cloud Databases-Delegierendenautorisierung löschen, kann ab sofort keine der Bereitstellungen, die denselben Schlüssel verwenden, Sicherungen ausführen, und die entsprechenden Autorisierungen können nicht mehr neu erstellt werden, wodurch die Sicherungen aller Bereitstellungen, die denselben Schlüssel verwenden, wirkungsvoll zerstört werden.

Lassen Sie bei der Wiederverwendung von Schlüsseln Vorsicht walten.