Verschlüsselung in S3: SSE-S3, SSE-KMS und SSE-C – wer hält den Schlüssel zu Ihren Dateien?

WebDisk-Blog · Kategorie: Sicherheit · Lesezeit: ~12 Minuten

Kurz gefasst:- SSE-S3 – die Schlüssel verwaltet der Objektspeicher; einschalten und vergessen.- SSE-KMS – die Schlüssel leben in einem externen Tresor (KMS); Sie gewinnen Audit, Rotation und Rechtetrennung.- SSE-C – den Schlüssel übergeben Sie bei jeder Anfrage, der Server speichert ihn nicht; maximale Kontrolle und volle Verantwortung. >Sie arbeiten nicht mit dem Terminal? Sie können die Code-Beispiele getrost überspringen – die Vergleichstabelle und der Abschnitt über WebDisk Files und Send vermitteln das vollständige Bild.

Wenn Sie eine Datei in die Cloud hochladen, passiert im Hintergrund etwas, worüber wir selten nachdenken: Ihre Daten landen auf physischen Festplatten in irgendeinem Rechenzentrum. Was geschieht, wenn eine solche Festplatte im Rahmen einer Wartung ausgetauscht wird und das Rechenzentrum verlässt? Oder wenn ein Backup in unbefugte Hände gerät? Die Antwort auf diese Fragen ist die Verschlüsselung ruhender Daten (Encryption at Rest) – und in der Welt des S3-Protokolls, das auch unsere Plattform spricht, hat sie drei Standardvarianten: SSE-S3, SSE-KMS und SSE-C.

Sie unterscheiden sich in einem einzigen, aber fundamentalen Detail: darin, wer den Verschlüsselungsschlüssel erzeugt, speichert und kontrolliert. In diesem Artikel erklären wir, wie jede Variante funktioniert, zeigen an Beispielen, wie Sie sie selbst verwenden, und beschreiben die praktische Nutzung in den Diensten WebDisk Files und WebDisk Send.

Worin unterscheidet sich die Verschlüsselung bei der Übertragung von der Verschlüsselung im Ruhezustand?

Bevor wir zu SSE kommen, bringen wir Ordnung in die Begriffe, denn „Verschlüsselung“ ist oft ein Sammelbegriff, in den ganz verschiedene Dinge geworfen werden:

• Die Verschlüsselung bei der Übertragung schützt die Daten auf dem Weg zwischen Ihnen und dem Server. Das ist die Aufgabe von TLS – derselben Technologie, die hinter dem Schloss-Symbol im Browser steckt. Ohne TLS könnte jemand, der das Netzwerk abhört (z. B. in einem offenen WLAN), die übertragene Datei abfangen.
• Die Verschlüsselung im Ruhezustand schützt die Daten, die auf den Festplatten liegen. Selbst wenn jemand physisch in den Besitz des Datenträgers oder der rohen Dateien vom Server gelangt, sieht er nur kryptografisches Rauschen.

Diese Mechanismen ergänzen einander, statt sich zu ersetzen. Die gesamte Kommunikation mit den WebDisk-Diensten läuft immer über TLS – das ist die Pflichtschicht. Die Verschlüsselung im Ruhezustand ist die zweite Schicht, und um sie geht es in diesem Artikel.

Server-Side Encryption (SSE) bedeutet, dass der Server die Verschlüsselung übernimmt: Die Daten kommen über TLS an, der Server verschlüsselt sie vor dem Schreiben auf die Festplatte, beim Herunterladen entschlüsselt er sie wieder. Die Alternative ist die Verschlüsselung auf Client-Seite (client-side / end-to-end), bei der der Server von Anfang bis Ende ausschließlich das Chiffrat sieht – die verschlüsselte, unlesbare Form der Daten. Wir kommen in den FAQ auf diese Unterscheidung zurück, denn sie ist wichtig für eine ehrliche Bewertung der Garantien.

Wie funktioniert die Umschlagverschlüsselung (Envelope Encryption)?

Alle drei Varianten verschlüsseln die Daten mit demselben bewährten Algorithmus: AES-256 – einer symmetrischen Blockchiffre, die bei korrekter Implementierung außerhalb der Reichweite jedes bekannten Brute-Force-Angriffs liegt. Wirklich interessant ist, was mit den Schlüsseln geschieht.

Die ersten beiden Varianten – SSE-S3 und SSE-KMS – nutzen die sogenannte Umschlagverschlüsselung (Envelope Encryption):

1. Jedes Objekt (jede Datei) wird mit einem eigenen, einmaligen Datenschlüssel (DEK – Data Encryption Key) verschlüsselt.
2. Der Datenschlüssel ist seinerseits mit einem übergeordneten Schlüssel (KEK – Key Encryption Key) verschlüsselt und wird erst in dieser verschlüsselten Form in den Metadaten des Objekts gespeichert.
3. Der übergeordnete Schlüssel liegt nie neben den Daten – und wo er lebt und wer ihn verwaltet, das unterscheidet SSE-S3 von SSE-KMS.

Dank des Umschlags legt die Kompromittierung eines einzelnen Datenschlüssels nur eine Datei offen, nicht das ganze Archiv; die Rotation des übergeordneten Schlüssels erfordert auch keine Neuverschlüsselung von Petabytes an Daten – es genügt, die kleinen Datenschlüssel umzuschlüsseln.

SSE-C funktioniert anders: Der vom Client gelieferte Schlüssel verschlüsselt das Objekt direkt. Der Server erzeugt keinen Datenschlüssel und speichert keinen umhüllten Schlüssel – er bewahrt ausschließlich einen Hash des Schlüssels auf, um bei späteren Anfragen zu prüfen, dass derselbe Schlüssel übergeben wurde.

Aus Sicht des S3-Nutzers läuft die Wahl der Variante auf HTTP-Header hinaus, die beim Schreiben des Objekts (PUT) gesendet werden. Das Lesen ist – außer bei SSE-C – transparent: Der Server erkennt selbst, dass das Objekt verschlüsselt ist, und entschlüsselt es beim Herunterladen, sofern Sie das Zugriffsrecht auf das Objekt haben (und bei der Variante SSE-KMS – auch das Recht, den Schlüssel im KMS zu verwenden).

Bevor Sie beginnen: Konfiguration des Clients. Die Beispiele verwenden das offizielle aws CLI, das mit jedem S3-kompatiblen Speicher funktioniert. Sie benötigen ein Paar Zugangsschlüssel (Access Key + Secret Key) von Ihrem Anbieter – in den WebDisk-Diensten finden Sie sie im Panel. Konfigurieren Sie sie einmalig:

aws configure # Access Key und Secret Key angeben (Region: z. B. us-east-1)

Liegt Ihr Speicher nicht bei AWS, ergänzen Sie jeden Befehl um den Endpoint Ihres Anbieters:

aws --endpoint-url https://s3.twoj-dostawca.example s3 ls

Der Lesbarkeit halber lassen wir in den weiteren Beispielen --endpoint-url weg – denken Sie daran, wenn Sie nicht AWS verwenden.

Was ist SSE-S3 und wovor schützt es?

Das ist die Variante „einschalten und vergessen“. Datenschlüssel und übergeordneten Schlüssel erzeugt, speichert und rotiert der Objektspeicher selbst. Der Nutzer sieht keinen einzigen Schlüssel – er erklärt nur den Wunsch nach Verschlüsselung.

Technisch genügt ein einziger Header beim Schreiben:

x-amz-server-side-encryption: AES256

In der Praxis fügt man ihn selten manuell jeder Anfrage hinzu. Bequemer ist die Standardverschlüsselung des Buckets (ein Bucket ist der Container für Objekte in S3 – das Gegenstück zu einem Laufwerk oder einer Freigabe; in den WebDisk-Diensten nennen wir ihn Speicher). Ab dem Moment der Aktivierung wird jedes neu geschriebene Objekt automatisch verschlüsselt, unabhängig davon, ob der Client darum gebeten hat. Genau so funktioniert übrigens heute AWS – seit Januar 2023 werden dort alle neuen Objekte in S3 standardmäßig mit SSE-S3 verschlüsselt. In Ceph RGW (der Engine unserer Plattform) konfiguriert man die Standardverschlüsselung des Buckets mit einem identischen API-Aufruf.

# einzelne Datei mit expliziter Verschlüsselungsanforderung
aws s3 cp raport.pdf s3://moj-bucket/ --sse AES256

# oder ein für alle Mal: Standardverschlüsselung des gesamten Buckets
aws s3api put-bucket-encryption --bucket moj-bucket \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

# Verifikation: Ist das Objekt verschlüsselt?
aws s3api head-object --bucket moj-bucket --key raport.pdf
# in der Antwort: "ServerSideEncryption": "AES256"

Was SSE-S3 bietet: Schutz vor „physischen“ Szenarien – eine entwendete Festplatte, ein Datenträger nach einem Ausfall, rohe aus dem Dateisystem des Servers kopierte Dateien sind nutzlos.

Was es nicht bietet: Schutz vor der Kompromittierung des Kontos. Wer das Leserecht auf ein Objekt hat, bekommt es entschlüsselt – der Server erledigt das automatisch. Gestohlene API-Schlüssel bedeuten Zugriff auf lesbare Daten, genau wie ohne Verschlüsselung. Das ist kein Implementierungsfehler, sondern die Grenze des Modells: SSE-S3 schützt Datenträger, nicht das Konto.

Was bietet SSE-KMS, also Schlüssel im externen Tresor?

SSE-KMS funktioniert wie SSE-S3, aber der übergeordnete Schlüssel gehört nicht mehr dem Objektspeicher, sondern einem externen Schlüsselverwaltungsdienst (KMS – Key Management Service). Der Objektspeicher muss bei jeder Operation das KMS um die Entschlüsselung des Datenschlüssels bitten – und hier zeigen sich drei praktische Vorteile:

1. Rechtetrennung. Der Zugriff auf das Objekt und der Zugriff auf den Schlüssel sind zwei unabhängige Entscheidungen. Man kann das Recht zur Nutzung des Schlüssels entziehen – und die Daten werden unlesbar, selbst für jemanden, der weiterhin Zugriff auf den Bucket hat.
2. Audit. Jede Nutzung des Schlüssels hinterlässt eine Spur in den KMS-Logs: wer, wann, wofür. Für die Compliance (DSGVO, ISO 27001) ist das oft eine harte Anforderung.
3. Lebenszyklus des Schlüssels. Rotation, Deaktivierung, Widerruf – zentral verwaltet, pro Schlüssel, ohne die Daten anzufassen. Viele KMS-Implementierungen erlauben es auch, eigenes Schlüsselmaterial mitzubringen (BYOK – Bring Your Own Key).

Beim Schreiben deklariert man die Variante aws:kms und optional die Schlüssel-ID:

x-amz-server-side-encryption: aws:kms
x-amz-server-side-encryption-aws-kms-key-id: <schluessel-id>

# in AWS erstellen Sie zuerst einen Schlüssel im KMS-Dienst und geben ihm einen Alias
aws kms create-key --description "Schluessel fuer Firmendokumente"
aws kms create-alias --alias-name alias/moj-klucz-firmowy \
  --target-key-id <KeyId-aus-dem-vorherigen-Befehl>

# Upload mit SSE-KMS unter Angabe eines konkreten Schlüssels
aws s3 cp raport.pdf s3://moj-bucket/ \
  --sse aws:kms --sse-kms-key-id alias/moj-klucz-firmowy

In AWS übernimmt der Dienst AWS KMS die Rolle des KMS. In der Welt von Ceph RGW kann das KMS-Backend u. a. HashiCorp Vault sein oder dessen offener Fork OpenBao – und das ist der Weg, den wir bei WebDisk gewählt haben: Die Verschlüsselungsschlüssel leben in einem separaten, abgeschotteten kryptografischen Tresor, und die Objektserver holen sie bei Bedarf über einen authentifizierten Kanal, ohne sie auf der Festplatte neben den Daten zu speichern. Die Schlüssel-ID aus dem Header entspricht dann dem Namen des Schlüssels im Tresor.

In den WebDisk-Diensten arbeitet SSE-KMS „unter der Haube“ der Plattform – es ist keine Option, die Sie selbst anklicken. Die Entscheidungen, die wir direkt in die Hände der Nutzer legen, sind SSE-S3 (verschlüsselte Speicher in Files) und SSE-C (Organisationsschlüssel in Files) – zu beiden gleich mehr.

Der Kompromiss: SSE-KMS ist ein zusätzliches bewegliches Teil (das KMS muss verfügbar sein, damit die Daten lesbar sind) und ein Overhead für die Kommunikation mit dem Tresor. Im Gegenzug erhalten wir Audit, zentrale Verwaltung und die Möglichkeit, die Daten mit einem Handgriff „abzuschneiden“.

Wie funktioniert SSE-C und welche Konsequenzen hat es?

Die dritte Variante vertauscht die Rollen: den Schlüssel erzeugt und speichert der Client, und der Server führt nur die Verschlüsselung aus. Bei jeder Anfrage – beim Schreiben und beim Lesen – übermittelt der Client seinen 256-Bit-Schlüssel in den Headern:

x-amz-server-side-encryption-customer-algorithm: AES256
x-amz-server-side-encryption-customer-key: <Base64-kodierter Schlüssel>
x-amz-server-side-encryption-customer-key-MD5: <MD5-Summe des Schlüssels, Base64>

Der Server verwendet den Schlüssel zum Verschlüsseln des Objekts, danach verwirft er den Schlüssel – er speichert ihn nirgendwo. Er merkt sich lediglich einen kryptografischen Fingerabdruck des Schlüssels (AWS S3 – zufällig gesalzener HMAC, Ceph RGW – MD5-Summe des Schlüssels): ausreichend, um bei späteren Anfragen zu erkennen, dass derselbe Schlüssel übergeben wurde, aber nutzlos für seine Rekonstruktion.

Die Konsequenzen sind gravierend, und man muss sie vor der Nutzung verstehen:

• Schlüsselverlust = Datenverlust. Unwiderruflich. Der Anbieter hat keine Kopie und kein Wiederherstellungsverfahren – das ist keine Marketingaussage, sondern eine Eigenschaft der Konstruktion.
• TLS ist Pflicht. Der Schlüssel wandert im HTTP-Header, daher weist der Server SSE-C-Anfragen ab, die ohne verschlüsselte Verbindung eintreffen (in Ceph RGW wacht darüber die Option rgw_crypt_require_ssl, standardmäßig aktiviert).
• Gewöhnliche Links reichen nicht mehr aus. Die meisten Mechanismen zum Teilen von Dateien aus S3 basieren auf der sogenannten Presigned URL – einem Link mit eingebauter, zeitlich begrenzter Berechtigungssignatur, dank derer man ein Objekt ohne Anmeldung herunterladen kann. Eine Presigned URL signiert die Anfrage, schmuggelt aber die Header mit dem Schlüssel nicht hindurch – wer herunterlädt, muss den Schlüssel trotzdem kennen. Ein Browser, der nur den Link bekommen hat, wird ein SSE-C-Objekt nicht herunterladen. Anwendungen müssen diesen Fall gesondert behandeln (gleich zeigen wir, wie Files das macht).

Ein Beispiel von Grund auf, unter Verwendung von openssl und aws CLI:

# 1. Erzeugen Sie einen 32-Byte-Schlüssel (256 Bit) und verwahren Sie ihn an einem sicheren Ort
openssl rand -out sse-c.key 32

# 2. Upload mit SSE-C
aws s3 cp tajne.pdf s3://moj-bucket/tajne.pdf \
  --sse-c AES256 --sse-c-key fileb://sse-c.key

# 3. Download — erfordert DENSELBEN Schlüssel
aws s3 cp s3://moj-bucket/tajne.pdf pobrane.pdf \
  --sse-c AES256 --sse-c-key fileb://sse-c.key

# 4. Der Versuch, ohne Schlüssel herunterzuladen, endet mit Fehler 400
aws s3 cp s3://moj-bucket/tajne.pdf test.pdf

Hinweis für Nutzer von AWS S3: seit April 2026 ist bei neuen Buckets (sowie bei bestehenden auf Konten, die keine SSE-C-Objekte hatten) das Schreiben mit SSE-C standardmäßig blockiert – ein Upload mit SSE-C-Headern liefert den Fehler 403 AccessDenied. Sie entsperren es einmalig:

aws s3api put-bucket-encryption --bucket moj-bucket \
  --server-side-encryption-configuration \
  '{"Rules":[{"BlockedEncryptionTypes":{"EncryptionType":["NONE"]}}]}'

Das Lesen zuvor geschriebener SSE-C-Objekte funktioniert unverändert. Auf Ceph-RGW-Speichern – einschließlich der WebDisk-Dienste – funktioniert SSE-C sofort, ohne diesen Schritt.

Dasselbe programmatisch in Python (boto3 kodiert den Schlüssel selbst in Base64 und berechnet die MD5-Summe dazu):

import boto3, os

s3 = boto3.client("s3", endpoint_url="https://s3.twoj-dostawca.example")

key = os.urandom(32) # 256-Bit-Schlüssel — bewahren Sie ihn sicher auf!

with open("tajne.pdf", "rb") as f:
    s3.put_object(
        Bucket="moj-bucket", Key="tajne.pdf", Body=f,
        SSECustomerAlgorithm="AES256",
        SSECustomerKey=key,
    )

obj = s3.get_object(
    Bucket="moj-bucket", Key="tajne.pdf",
    SSECustomerAlgorithm="AES256",
    SSECustomerKey=key,
)

Eine wichtige Nuance der vollen Ehrlichkeit halber: Bei SSE-C sieht der Server den Schlüssel und den Inhalt der Datei während der Bearbeitung der Anfrage (im Arbeitsspeicher, für die Dauer der Operation) – er sieht sie jedoch nie nach deren Abschluss. Wenn die Anforderung lautet, dass der Server die Inhalte zu keinem Zeitpunkt sieht, brauchen Sie Verschlüsselung auf Client-Seite, nicht SSE.

SSE-S3, SSE-KMS oder SSE-C – welche Variante wählen?

• Wer den übergeordneten Schlüssel erzeugt – SSE-S3: der Objektspeicher · SSE-KMS: der KMS-Dienst · SSE-C: der Client
• Wo er gespeichert wird – SSE-S3: innerhalb des Speichers · SSE-KMS: im KMS (Tresor außerhalb des Speichers) · SSE-C: ausschließlich beim Client
• Was der Server speichert – SSE-S3: alles · SSE-KMS: verschlüsselte Datenschlüssel · SSE-C: Chiffrat + Hash des Schlüssels
• Schlüsselverlust auf Client-Seite – SSE-S3: unmöglich · SSE-KMS: unmöglich · SSE-C: Datenverlust
• Audit und Schlüsselrotation – SSE-S3: intern, automatisch · SSE-KMS: zentral, sichtbar, pro Schlüssel · SSE-C: vollständig auf Client-Seite
• Aufwand für den Nutzer – SSE-S3: null · SSE-KMS: gering (Schlüsselverwaltung im KMS) · SSE-C: hoch (volle Verantwortung)
• Typisches Szenario – SSE-S3: vernünftiger Default-Standard · SSE-KMS: Compliance, Audit, BYOK · SSE-C: maximale Kontrolle über den Schlüssel

Eine einfache Auswahlregel: SSE-S3, wenn Sie einfach verschlüsselte Daten im Ruhezustand haben und nichts verwalten möchten; SSE-KMS, wenn der Auditor fragt, „wer wann den Schlüssel verwendet hat“, oder die Unternehmensrichtlinie eine Kontrolle des Schlüssel-Lebenszyklus verlangt; SSE-C, wenn der Schlüssel ausschließlich in Ihren Händen liegen soll – und Sie bereit sind, die Konsequenzen zu tragen.

Wie wir es bei WebDisk machen: Files und Send

Theorie ergibt Sinn, wenn man sie in einem funktionierenden Produkt sieht. Unsere beiden Dateidienste positionieren sich bewusst an den beiden Enden des Spektrums „Einfachheit ↔ Kontrolle“.

WebDisk Files – Schichten zur Auswahl

Files ist unsere Plattform für die sichere Speicherung von Dateien für Unternehmen. Die Verschlüsselung ist darin schichtweise aufgebaut, und die beiden SSE-Mechanismen aus diesem Artikel treten in den Rollen auf, in die sie am besten passen:

• SSE-S3 auf Speicherebene. Beim Anlegen eines zusätzlichen Speichers (Buckets) lässt sich mit einem einzigen Schalter seine dauerhafte Verschlüsselung aktivieren. Von diesem Moment an wird jede Datei – hochgeladen über das Panel, die Desktop-Anwendung oder im Rahmen des Teilens – automatisch an der Quelle verschlüsselt, durch die Standardverschlüsselung des Buckets. Die Entscheidung ist eine Einbahnstraße (der Speicher lässt sich nicht per Schalter „entschlüsseln“), der Nutzer verwaltet keinen einzigen Schlüssel, und die übergeordneten Schlüssel liegen nicht neben den Daten – sie leben in einem dedizierten kryptografischen Tresor (OpenBao), mit einem eigenen Schlüssel für jeden Speicher.
• SSE-C auf Organisationsebene. Eine Organisation kann eine zusätzliche Verschlüsselung ausgewählter Dateien und Ordner mit dem SSE-C-Mechanismus aktivieren. Ein wichtiger Unterschied zum oben beschriebenen eigenständigen SSE-C: Den Schlüssel verwaltet hier nicht der Nutzer, sondern die Files-Anwendung im Namen der Organisation – beim Aktivieren der Funktion wird ein 256-Bit-Organisationsschlüssel erzeugt, der von der Anwendung in verschlüsselter Form außerhalb der Objektspeicherschicht aufbewahrt wird. Dadurch persistiert der Objektspeicher den Schlüssel nie – weder ein entwendeter Datenträger noch die Kompromittierung der Speicherschicht selbst legen diese Dateien offen – und zugleich trägt die Organisation nicht das Risiko eines unwiderruflichen Datenverlusts: Das Szenario „Schlüssel verloren – Daten weg“ betrifft die eigenständige Nutzung von SSE-C über die API, nicht diese Funktion. Der Ehrlichkeit halber muss man hinzufügen: In diesem Modell hat die Anwendung Zugriff auf den Schlüssel – und damit technisch auch der Anbieter; wenn die Anforderung lautet, dass der Anbieter die Inhalte zu keinem Zeitpunkt lesen kann, ist das richtige Werkzeug die Verschlüsselung auf Client-Seite (siehe FAQ). Die Konsequenzen des SSE-C-Protokolls behandelt die Anwendung selbst: Verschlüsselte Dateien lassen sich nicht über eine gewöhnliche Presigned URL herunterladen (diese transportiert keine Header mit dem Schlüssel), daher liefert Files sie über die Anwendung aus und streamt die Daten nach der Prüfung der Berechtigungen. SSE-C unterstützt auch unsere Desktop-Anwendung zur Ordnersynchronisierung.
• Komplementäre Schichten. Verschlüsselung schützt die Vertraulichkeit, schützt aber nicht davor, dass Dateien durch Ransomware auf dem Rechner des Nutzers überschrieben oder verschlüsselt werden. Deshalb bietet Files neben SSE Versionierung sowie den Modus Anti-Ransomware auf Basis von S3 Object Lock im Compliance-Modus – eine Unveränderlichkeitssperre, die von der Objektspeicherschicht durchgesetzt wird und selbst einer Kompromittierung der Anwendung standhält. Das vollständige Sicherheitsbild ist immer die Summe der Schichten, nicht ein einzelner Mechanismus.

WebDisk Send – Sicherheit ohne Bedienungsanleitung

Send löst ein anderes Problem: „Ich habe eine große Datei und will sie jemandem schicken, sofort.“ Beim Entwurf haben wir die Option der Verschlüsselung pro Datei aus Files bewusst nicht übernommen – denn ein Dienst, dessen Stärke der Verzicht auf Konfiguration ist, sollte das Gespräch nicht mit einer Frage nach Schlüsseln beginnen.

Die Sicherheit von Send stützt sich auf Mechanismen, die zum Szenario passen: Übertragung ausschließlich über TLS, optionales Passwort für den Link (es kontrolliert den Zugriff auf den Download – es ist kein Schlüssel, der den Inhalt verschlüsselt), Download-Limit und Ablaufdatum, und vor allem die Retention – Dateien leben so lange, wie es der Plan vorsieht, und werden danach automatisch und dauerhaft gelöscht. Die sicherste Datei ist die, die es nicht mehr gibt. Die Daten liegen dabei auf derselben Ceph-Objektplattform, die wir oben beschrieben haben – mit demselben operativen Unterbau.

Wenn Sie eine von Ihnen selbst gesteuerte Verschlüsselung brauchen – verschlüsselte Speicher, einen Organisationsschlüssel, Retention-Richtlinien und Sperren –, ist das ein Signal, dass Ihr Werkzeug Files ist, nicht Send. Diese Aufteilung ist beabsichtigt.

Häufige Fragen

Worin unterscheidet sich SSE-S3 von SSE-KMS und SSE-C? Alle drei Varianten verschlüsseln die Daten mit demselben AES-256-Algorithmus – sie unterscheiden sich darin, wer den Schlüssel verwaltet. Bei SSE-S3 erzeugt, speichert und rotiert die Schlüssel der Objektspeicher selbst; bei SSE-KMS lebt der übergeordnete Schlüssel in einem externen Tresor (KMS), was Audit, Rotation und Rechtetrennung bringt; bei SSE-C übergibt der Client den Schlüssel bei jeder Anfrage, und der Server speichert ihn nicht. Das Risiko eines Schlüsselverlusts auf Client-Seite existiert ausschließlich bei SSE-C – und bedeutet einen unwiderruflichen Datenverlust.

Verlangsamt die Verschlüsselung im Ruhezustand Upload und Download? In der Praxis nicht. Moderne Prozessoren haben Hardware-Unterstützung für AES (AES-NI), und die Verschlüsselung erfolgt im Datenstrom. Bei SSE-KMS kommt eine kurze Kommunikation mit dem Schlüsseltresor hinzu, vernachlässigbar im Vergleich zur Übertragung der Datei.

Schützt mich SSE-S3, wenn jemand mein Passwort oder meine API-Schlüssel stiehlt? Nein – und keine SSE-Variante hat diese Aufgabe. Der Server entschlüsselt die Daten für jeden, der gültige Berechtigungen hat. Vor dem Diebstahl von Zugangsdaten schützen starke Passwörter, MFA und API-Schlüssel-Hygiene; vor den Folgen – Versionierung und Object Lock.

Ich habe den SSE-C-Schlüssel verloren. Was nun? Nichts. Das ist kein Szenario der Art „wenden Sie sich an den Support“ – der Server hat den Schlüssel nicht, der Anbieter hat ihn nicht, niemand hat ihn. Die Daten sind kryptografisch nicht wiederherstellbar. Deshalb bewahrt man SSE-C-Schlüssel in einem Secret-Manager auf und bindet sie in Unternehmensprozeduren ein (Kopien, Hinterlegung, Nachfolgeregelung). Das Obige betrifft die eigenständige Nutzung von SSE-C über die S3-API – im Dienst Files verwaltet die Anwendung den SSE-C-Schlüssel im Namen der Organisation, dieses Szenario tritt dort also nicht auf.

Worin unterscheidet sich SSE von der End-to-End-Verschlüsselung? Bei SSE verschlüsselt der Server – im Moment des Schreibens und Lesens sieht er also den Inhalt (und bei SSE-C auch den Schlüssel) im Arbeitsspeicher. Bei der Client-Verschlüsselung (End-to-End) wird die Datei noch auf Ihrem Gerät verschlüsselt, und der Server sieht nie den Inhalt oder den Schlüssel – um den Preis des Verlusts von Funktionen, die den Inhalt serverseitig benötigen (Vorschauen, Suche, ZIP eines Ordners). Das sind zwei verschiedene Punkte auf der Vertrauensachse; SSE-C ist die am weitesten vorgeschobene Variante auf der Serverseite.

Woran erkenne ich, dass ein Objekt verschlüsselt ist? aws s3api head-object liefert den Header x-amz-server-side-encryption (AES256 oder aws:kms) – ein gutes, schnelles Audit der eigenen Buckets. Vorsicht bei SSE-C: head-object auf einem solchen Objekt liefert ohne Angabe des Schlüssels den Fehler 400 Bad Request – und genau dieser Fehler ist das Signal, dass das Objekt mit einem Client-Schlüssel verschlüsselt ist; den Header x-amz-server-side-encryption-customer-algorithm sehen Sie erst in der Antwort auf eine Anfrage mit dem Schlüssel.

Ich verwende rclone, nicht das aws CLI. Geht das? Ja – rclone unterstützt alle drei Varianten in der Konfiguration des S3-Remotes: server_side_encryption = AES256 (SSE-S3), server_side_encryption = aws:kms + sse_kms_key_id (SSE-KMS) oder sse_customer_algorithm = AES256 + sse_customer_key_base64 (SSE-C).

Zusammenfassung

Die Verschlüsselung im Ruhezustand in S3 ist nicht eine einzelne Funktion, sondern ein Spektrum von Vertrauensmodellen:

• SSE-S3 – der Server verwaltet die Schlüssel; null Aufwand, Schutz von Datenträgern und Kopien.
• SSE-KMS – Schlüssel im externen Tresor; Audit, Rotation, Rechtetrennung.
• SSE-C – der Schlüssel ausschließlich bei Ihnen; maximale Kontrolle, volle Verantwortung.

Bei WebDisk setzen wir diese Mechanismen dort ein, wo sie Sinn ergeben: Files legt die Wahl in die Hände des Organisationsadministrators (verschlüsselte SSE-S3-Speicher, optionale SSE-C-Verschlüsselung mit einem von der Anwendung verwalteten Organisationsschlüssel), Send nimmt dem Nutzer diese Wahl ab und rundet die Sicherheit mit Retention und Link-Passwörtern ab, und dort, wo die Verschlüsselung aktiviert ist, leben die Schlüssel in einem separaten Tresor – nicht neben den Daten. Verschlüsselung schützt dabei die Vertraulichkeit der Daten – ihr Überleben sichert die zweite Schicht: das Backup in der Cloud.

Möchten Sie das in der Praxis ausprobieren? Erstellen Sie ein kostenloses Konto bei WebDisk Send oder testen Sie WebDisk Files – und wenn Sie Fragen zur Verschlüsselung in Ihrer Organisation haben, schreiben Sie uns.

Dieser Artikel ist Teil einer Serie über Datensicherheit in den WebDisk-Diensten. Alle Beispiele können Sie auf jedem S3-kompatiblen Speicher ausführen (auf AWS S3 erfordert das SSE-C-Beispiel eine einmalige Entsperrung – siehe Kasten im Abschnitt über SSE-C); der Parameter --endpoint-url im aws CLI zeigt auf den Endpoint Ihres Anbieters.