Server-seitige Verschlüsselung mit IBM Key Protect (SSE-KP)

Sie können IBM Key Protect verwenden, um Schlüssel zu erstellen, hinzuzufügen und zu verwalten, die Sie dann mit Ihrer Instanz von IBM® Cloud Object Storage verknüpfen können, um Buckets zu verschlüsseln.

Vorbereitende Schritte

Bevor Sie Key Protect mit Cloud Object Storage-Buckets verwenden können, benötigen Sie:

Außerdem müssen Sie sicherstellen, dass eine Serviceinstanz mithilfe des IBM Cloud-Katalogs erstellt und die entsprechenden Berechtigungen erteilt werden. In diesem Abschnitt werden die Anleitungen in einzelnen Arbeitsschritten beschrieben, um Ihnen den Einstieg zu erleichtern.

Bereitstellung einer Instanz von IBM Key Protect

Anweisungen zur Bereitstellung und zur Einrichtung der entsprechenden Serviceinstanzen finden Sie auf den servicespezifischen Produktseiten.

Ab dem 1. Januar 2025 sind fünf Schlüsselversionen pro Konto nicht mehr kostenlos. Jede Schlüsselversion wird Ihnen in Rechnung gestellt, beginnend mit dem ersten erstellten Schlüssel.

Sobald Sie eine Instanz von Key Protecthaben, müssen Sie einen Rootschlüssel erstellen und den CRN (Cloud Resource Name) dieses Schlüssels notieren. Der CRN wird während der Erstellung eines Buckets in einem Header gesendet.

Bevor Sie das Bucket für die Verwendung mit Key Protecterstellen, lesen Sie die relevante Anleitung zu Verfügbarkeit und Disaster-Recovery.

Beachten Sie, dass die verwaltete Verschlüsselung für ein regionsübergreifendes Bucket einen Rootschlüssel aus einer Key Protect-Instanz am nächsten Hochverfügbarkeitsstandort (us-south, eu-de oder jp-tok) verwenden muss.

Schlüssel in Key Protect erstellen oder hinzufügen

Navigieren Sie zu Ihrer Instanz von Key Protect und generieren Sie einen Rootschlüssel oder geben Sie einen vorhandenen Rootschlüssel ein.

Serviceautorisierung erteilen

Autorisieren Sie Key Protect für die Verwendung mit IBM COS:

  1. Öffnen Sie das IBM Cloud-Dashboard.
  2. Klicken Sie in der Menüleiste auf Verwalten > Zugriff (IAM).
  3. Klicken Sie in der Seitennavigation auf Autorisierungen.
  4. Klicken Sie auf Autorisierung erstellen.
  5. Wählen Sie im Menü Quellenservice die Option Cloud Object Storage aus.
  6. Wählen Sie im Menü Quellenserviceinstanz die Serviceinstanz aus, die autorisiert werden soll.
  7. Wählen Sie im Menü "Zielservice" IBM Key Protect.
    Abbildung 1: Serviceberechtigung für Key Protecterteilen.
    Serviceberechtigung erteilen
  8. Wählen Sie im Menü Zielserviceinstanz die Serviceinstanz, die autorisiert werden soll, aus. Die zusätzlichen Felder können leer bleiben.
  9. Aktivieren Sie die Rolle Leseberechtigter.
  10. Klicken Sie auf Autorisieren.

Bucket erstellen

Wenn Ihr Schlüssel in Key Protect existiert und Sie den Dienst für die Verwendung mit IBM COS autorisiert haben, verknüpfen Sie den Schlüssel mit einem neuen Bucket:

  1. Navigieren Sie zu Ihrer Instanz von Object Storage.
  2. Klicken Sie auf Bucket erstellen.
  3. Wählen Sie Angepasstes Bucket aus.
  4. Geben Sie einen Bucketnamen ein, wählen Sie den Ausfallsicherheitstyp Regional und dann einen Standort und eine Speicherklasse aus.
  5. Aktivieren Sie in Serviceintegration die Option Schlüsselmanagement inaktiviert, um das Chiffrierschlüsselmanagement zu aktivieren, und klicken Sie auf Vorhandene Instanz verwenden.
  6. Wählen Sie die zugeordnete Serviceinstanz und den zugehörigen Schlüssel aus und klicken auf Schlüssel zuordnen.
  7. Überprüfen Sie, ob die Informationen korrekt sind.
  8. Klicken Sie auf Erstellen.

Sie können Key Protect verwenden, um die Verschlüsselung für einen Bucket nur zum Zeitpunkt der Erstellung zu verwalten. Es ist nicht möglich, einen vorhandenen Eimer so zu ändern, dass er Key Protect verwendet.

Wenn die Bucketerstellung mit dem Fehler 400 Bad Request und der Nachricht The Key CRN could not be found fehlschlägt, dann müssen Sie sicherstellen, dass der CRN korrekt ist und dass die Service-zu-Service-Autorisierungsrichtlinie vorhanden ist.

In der Liste Buckets verfügt das Bucket über einen Link Ansicht unter Attribute, über den Sie überprüfen können, ob für das Bucket der Schlüssel Key Protect aktiviert ist.

Beachten Sie, dass der Wert Etag, der für mit SSE-KP verschlüsselte Objekte zurückgegeben wird, der tatsächliche MD5-Hash des ursprünglichen entschlüsselten Objekts ist.

Es ist auch möglich, die REST-API oder SDKs (Go, Java, Node.js oder Python) zu verwenden.

Management des Schlüssellebenszyklus

Key Protect bietet verschiedene Möglichkeiten zur Verwaltung des Lebenszyklus von Verschlüsselungsschlüsseln. Weitere Details finden Sie in der Dokumentation zu Key Protect.

Schlüssel turnusmäßig wechseln

Die Schlüsselrotation ist ein wichtiger Teil, um das Risiko von Datenschutzverletzungen zu mindern. Durch die regelmäßige Änderung von Schlüsseln wird das Risiko eines potenziellen Datenverlusts reduziert, falls der Schlüssel verloren gehen sollte oder beschädigt wird. Die Häufigkeit, mit der die Schlüssel gewechselt werden, kann von Organisation zu Organisation variieren und hängt von einer Reihe von Faktoren wie beispielsweise der Umgebung, des Volumens an verschlüsselten Daten, der Klassifizierung der Daten und der gesetzlichen Complianceregelungen ab. Das National Institute of Standards and Technology(NIST ) definiert geeignete Schlüssellängen und gibt Richtlinien für die Nutzungsdauer von Schlüsseln vor.

Weitere Informationen finden Sie in der Dokumentation für rotierende Schlüssel in Key Protect.

Schlüssel inaktivieren und erneut aktivieren

Als Administrator müssen Sie gegebenenfalls vorübergehend einen Rootschlüssel inaktivieren, wenn Sie bei Ihren Daten eine potenzielle Sicherheitslücke, ein Sicherheitsrisiko oder einen Verstoß gegen den Datenschutz vermuten. Beim Inaktivieren eines Rootschlüssels werden die zugehörigen Ver- und Entschlüsselungsoperationen ausgesetzt. Nachdem Sie bestätigt haben, dass kein Sicherheitsrisiko mehr besteht, können Sie den Zugriff auf Ihre Daten wiederherstellen, indem Sie den deaktivierten Root-Schlüssel aktivieren.

Wenn ein Schlüssel inaktiviert und anschließend schnell wieder aktiviert wird, können Anforderungen an dieses Bucket bis zu einer Stunde lang zurückgewiesen werden, bevor die zwischengespeicherten Schlüsselinformationen aktualisiert werden.

Löschen von Schlüsseln und kryptografischen Löschungen

Es ist nicht möglich, einen Rootschlüssel zu löschen, der einem Bucket mit einer Aufbewahrungsrichtlinie zugeordnet ist. Das Bucket muss zuerst geleert und gelöscht werden, bevor der Rootschlüssel gelöscht werden kann. Weitere Informationen finden Sie in der Key Protect-Dokumentation.

Kryptografisches Löschen (oder kryptografisches Schreddern) ist eine Methode, um verschlüsselte Daten durch Löschen der Verschlüsselungsschlüssel und nicht durch die Daten selbst nicht lesbar zu machen. Wenn ein -Rootschlüssel in Key Protect gelöscht wird, wirkt sich dies auf alle Objekte in allen Buckets aus, die mit diesem Rootschlüssel erstellt wurden. Dies bedeutet, dass die Daten geschreddert und weitere Lese-oder Schreibvorgänge in den Buckets verhindert werden. Dieser Prozess erfolgt nicht sofort, sondern innerhalb von etwa 90 Sekunden, nachdem der Schlüssel gelöscht wurde.

Obwohl Objekte in einem Crypto-Shredded-Bucket nicht gelesen und neue Objekte nicht geschrieben werden können, verbrauchen vorhandene Objekte weiterhin Speicher, bis sie von einem Benutzer gelöscht werden.

Gelöschten Schlüssel wiederherstellen

Als Administrator müssen Sie möglicherweise einen Root-Schlüssel wiederherstellen, den Sie in Key Protect importiert haben, damit Sie auf Daten zugreifen können, die zuvor durch den Schlüssel geschützt waren. Wenn Sie einen Schlüssel wiederherstellen, verschieben Sie den Schlüssel vom Status "Zerstört" in den Status "Aktiv" und stellen den Zugriff auf alle Daten wieder her, die zuvor mit dem Schlüssel verschlüsselt wurden. Dies muss innerhalb von 30 Tagen nach dem Löschen eines Schlüssels erfolgen.

Activity Tracking

Wenn Key Protect-Rootschlüssel gelöscht, gewechselt, ausgesetzt, aktiviert oder zurückgeschrieben werden, wird zusätzlich zu allen Ereignissen, die von Key Protectprotokolliert werden, ein Activity Tracker-Managementereignis (cloud-object-storage.bucket-key-state.update) generiert.

Bei einem serverseitigen Fehler in einer Lebenszyklusaktion für einen Schlüssel wird dieser Fehler von COS nicht protokolliert. Wenn Key Protect innerhalb von vier Stunden nach dem gesendeten Ereignis keinen Erfolg von COS für die Ereignisverarbeitung empfängt, protokolliert Key Protect einen Fehler.

Die cloud-object-storage.bucket-key-state.update-Aktionen werden durch Ereignisse ausgelöst, die in Key Protectstattfinden, und erfordern, dass das Bucket beim Key Protect-Service registriert wird. Diese Registrierung erfolgt automatisch, wenn ein Bucket mit einem Key Protect-Rootschlüssel erstellt wird.

Buckets, die vor dem 26. Februar 26th, 2020 erstellt wurden, werden nicht beim Key Protect-Service registriert und empfangen zu diesem Zeitpunkt keine Benachrichtigungen über Lebenszyklusereignisse für Verschlüsselungsschlüssel. Sie können diese Buckets ermitteln, indem Sie eine Operation zum Auflisten von Buckets ausführen und die Datumsangaben für die Bucketerstellung anzeigen. Um sicherzustellen, dass diese Buckets den neuesten Schlüsselstatus aus Key Protectaufweisen, wird empfohlen, einige Datenoperationen auszuführen, wie z. B. PUT, GET oder HEAD für ein Objekt in jedem betroffenen Bucket. Es wird empfohlen, eine Objektoperation zweimal (mindestens eine Stunde) auszuführen, um sicherzustellen, dass der Schlüsselstatus ordnungsgemäß mit dem Status Key Protect synchronisiert wird.

Weitere Informationen zu Activity Tracker-Ereignissen für Objektspeicher finden Sie im Referenzthema.