STS in der Praxis: Zugriff auf S3 mit dem Firmenkonto (SSO), ohne statische Schlüssel

WebDisk Blog · Kategorie: Sicherheit · Lesezeit: ~11 Minuten

Kurz gefasst:- Statische S3-Schlüssel sind Geheimnisse ohne Ablaufdatum – sie werden geleakt, niemand rotiert sie, und das Ausscheiden eines Mitarbeiters aus dem Unternehmen macht sie nicht ungültig.- STS (Security Token Service) vergibt temporäre Zugangsdaten: Sie gelten eine Stunde oder ein paar Stunden, danach werden sie wertlos.- Die Kombination von STS mit der Unternehmensanmeldung (SSO) sorgt dafür, dass Sie den S3-Speicher mit Ihrem Firmenkonto betreten – und Berechtigungen und Zugriff an einem einzigen Ort verwaltet werden. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie die Code-Beispiele – die Funktionsbeschreibung und der Abschnitt über WebDisk vermitteln das vollständige Bild.

Stellen Sie sich vor, jeder Mitarbeiter erhält zum Start einen Universalschlüssel zum Büro — nachgemacht im Laden um die Ecke, ohne Registrierung, unbegrenzt gültig. Wenn jemand das Unternehmen verlässt, bleibt der Schlüssel in seiner Schublade. Wenn jemand ihn verliert, tauschen Sie die Schlösser aus… theoretisch, denn in der Praxis weiß niemand mehr, wie viele Schlüssel im Umlauf sind.

Klingt absurd? Genau so funktionieren aber die meisten S3-Implementierungen: ein statisches Schlüsselpaar (Access Key + Secret Key), einmal generiert, in Skripte, Konfigurationen und Notizen eingefügt – und jahrelang am Leben. In diesem Artikel zeigen wir eine Alternative, die die Cloud-Welt seit Langem einsetzt und die dennoch überraschend wenig bekannt ist: STS, also einen Dienst, der temporäre Zugangsdaten ausstellt, sowie seine interessanteste Anwendung — den Zugang zu S3 mit dem Firmenkonto per SSO. Am Ende beschreiben wir, wie wir bei WebDisk ein ganzes Produkt darauf aufgebaut haben.

Das Problem: ein Geheimnis, das niemals abläuft

Der klassische Zugriff auf S3 ist ein Paar: eine Schlüsselkennung (Access Key) und ein Geheimnis (Secret Key). Technisch ist das eine einfache und bequeme Lösung – deshalb hat sie sich so verbreitet. Sie hat jedoch vier Schwächen, die mit der Zeit nur größer werden:

• Ein Leak ist nur eine Frage der Zeit. Der Schlüssel landet in einem Skript, das Skript im Repository, das Repository auf GitHub. Automatische Scanner öffentlicher Repositories finden solche Geheimnisse wenige Minuten nach der Veröffentlichung.
• Rotation ist mühsam, also unterbleibt sie. Ein Schlüsselwechsel bedeutet, alle Stellen zu aktualisieren, an denen er eingefügt wurde – und niemand weiß, wie viele es sind. Das Ergebnis: Schlüssel leben jahrelang.
• Das Ausscheiden eines Mitarbeiters ändert nichts. Das Konto im Unternehmensverzeichnis wird gesperrt, aber der S3-Schlüssel ist ein eigenständiges Objekt – er funktioniert weiter, bis sich jemand beim Audit an ihn erinnert.
• Ein Schlüssel, viele Benutzer. In der Praxis teilen sich Teams Schlüssel, sodass das Ereignisprotokoll nur „jemand mit Schlüssel X“ sagt – ohne die Information, wer.

Alle diese Schwächen haben eine gemeinsame Ursache: die Zugangsdaten sind ewig gültig und von der Identität eines Menschen entkoppelt. Beheben lässt sich das nur auf eine Weise – Zugangsdaten müssen kurzlebig sein und auf Basis einer echten Unternehmensidentität ausgestellt werden.

Was ist STS und wie ersetzt es statische S3-Schlüssel?

STS (Security Token Service) ist ein Dienst aus der AWS-API-Familie – auch in Ceph RGW implementiert, dem Motor unserer Plattform – der genau eine Sache tut: er stellt temporäre Zugangsdaten aus. Statt eines ewigen Schlüsselpaares erhalten Sie ein Trio:

• einen temporären Access Key und Secret Key – sie sehen aus und funktionieren wie gewöhnliche S3-Schlüssel,
• Session Token – ein zusätzliches Element, das jeder Anfrage beigefügt wird,
• sowie ein Ablaufdatum – nach dessen Ablauf wird das gesamte Trio wertlos.

Die beste Analogie ist der Besucherausweis in einem Bürogebäude: Der Empfang prüft, wer Sie sind, druckt einen Ausweis, der bis 17:00 Uhr gültig ist – und das war's. Man muss ihn beim Verlassen nicht einsammeln, man muss keine Schlösser austauschen, wenn Sie ihn verlieren – er funktioniert morgen einfach nicht mehr.

Die entscheidende Frage lautet: auf welcher Grundlage stellt STS den Ausweis aus? Es gibt mehrere Wege (die Familie der Aufrufe AssumeRole*), aber uns interessiert der eleganteste: auf Basis eines Nachweises aus der Unternehmensanmeldung.

Wie verbindet man SSO mit S3? AssumeRoleWithWebIdentity Schritt für Schritt

Wenn Ihr Unternehmen SSO (Single Sign-on – eine Anmeldung für alle Anwendungen) hat, besitzt jeder Mitarbeiter bereits eine digitale Identität: ein Konto im Unternehmensverzeichnis, mit Passwort, MFA und Gruppenzugehörigkeit. Der Standard OpenID Connect (OIDC), auf dem die meisten modernen SSO-Systeme basieren, stellt nach der Anmeldung ein sogenanntes id_token aus – einen digital signierten „Personalausweis“: wer sich angemeldet hat, wo und für welche Anwendung.

Der STS-Aufruf namens AssumeRoleWithWebIdentity erlaubt es, diesen Nachweis gegen temporäre S3-Zugangsdaten einzutauschen. Schritt für Schritt:

1. Sie melden sich mit dem Firmenkonto an (SSO: Passwort, MFA – wie bei jeder anderen Anwendung). Sie erhalten ein id_token.
2. Sie legen das id_token dem STS-Dienst vor, wobei Sie die IAM-Rolle (IAM – Identity and Access Management, das Rollen- und Berechtigungssystem in der AWS/S3-Welt) angeben, die Sie annehmen möchten. Eine Rolle ist die Ausweisvorlage, die der Empfang im Ordner aufbewahrt: ein Satz von Richtlinien, die beschreiben, was dem Inhaber erlaubt ist (z. B. „Lese- und Schreibzugriff auf Buckets beginnend mit firma-“).
3. STS prüft den Nachweis: Es prüft die Signatur des Tokens beim Aussteller (Ihrem SSO), seine Gültigkeit und ob die Vertrauensrichtlinie der Rolle (Trust Policy) den Inhabern solcher Tokens erlaubt, diese Rolle anzunehmen.
4. Sie erhalten das Zugangsdaten-Trio – gültig z. B. für eine Stunde – und arbeiten mit S3 genau wie bisher: aws CLI, rclone, boto3, jedes beliebige S3-kompatible Werkzeug.
5. Nach dem Ablauf melden Sie sich erneut an (oder das Werkzeug aktualisiert die Zugangsdaten selbst – dazu weiter unten).

Beachten Sie die Aufgabentrennung: SSO beantwortet die Frage „wer sind Sie“, die IAM-Rolle – „was dürfen Sie“, und STS ist der Empfang, der das eine prüft und den Ausweis nach der Vorlage druckt. Diese Trennung ist der Kern der gesamten Konstruktion:

• Identitäten verwaltet die IT-Abteilung an einem einzigen Ort (dem Unternehmensverzeichnis) – eine Kontosperrung kappt den Zugriff auf alles auf einmal,
• Berechtigungen für Daten verwaltet der Dateneigentümer – über die Rollenrichtlinie, nicht über das Verteilen von Schlüsseln,
• und im Ereignisprotokoll hat jede Sitzung einen Namen, der sich einer Person zuordnen lässt. Ein Vorbehalt: Den Sitzungsnamen deklariert der Aufrufer, daher erfordert verlässliche Nachvollziehbarkeit, ihn über die Vertrauensrichtlinie oder den Broker zu erzwingen, der den Austausch durchführt (so machen wir es bei WebDisk – dazu weiter unten).

Technisches Detail am Rande: AssumeRoleWithWebIdentity ist einer der wenigen Aufrufe in der Welt der AWS-API, die keinerlei vorherige Zugangsdaten erfordern – Sie signieren ihn nicht mit einem Schlüssel, denn Ihre Authentifizierung ist das id_token selbst. Deshalb kann die gesamte Kette für einen Benutzer funktionieren, der keine statischen S3-Schlüssel hat und nie welche hatte.

Wie sieht eine IAM-Rolle aus und woraus besteht sie?

Eine Rolle besteht aus zwei Teilen, die man auseinanderhalten sollte, denn sie beantworten zwei verschiedene Fragen. In den Beispielen taucht der ARN (Amazon Resource Name) auf — die eindeutige Kennung einer Ressource in der AWS/S3-Welt: einer Rolle, eines Buckets oder eines Identitätsausstellers.

Die Vertrauensrichtlinie (Trust Policy) – wer die Rolle annehmen darf. Sie benennt den registrierten OIDC-Aussteller (Ihr SSO) und Bedingungen, z. B. dass das Token für eine bestimmte Anwendung ausgestellt sein muss:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::<konto>:oidc-provider/sso.firma.example/realms/firma" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": { "StringEquals": { "sso.firma.example/realms/firma:aud": "s3-firma" } }
  }]
}

Die Berechtigungsrichtlinien (Permission Policies) – was der Inhaber der Rolle tun darf. Ein gewöhnliches IAM-Dokument, z. B.:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:ListBucket", "s3:GetObject", "s3:PutObject"],
    "Resource": ["arn:aws:s3:::firma-*"]
  }]
}

Die genaue Syntax der Bedingungsschlüssel unterscheidet sich zwischen den Anbietern (AWS, Ceph RGW) — aber die Konstruktion ist immer dieselbe: Vertrauen zum Identitätsaussteller + Berechtigungsgrenzen.

Selbst ausprobieren: STS im Terminal und im Code

Bevor Sie beginnen. Sie benötigen drei Dinge vom Plattform-Administrator: die Adresse des S3/STS-Endpoints, den ARN der Rolle, die Sie annehmen dürfen, sowie ein gültiges id_token aus Ihrem SSO. Letzteres ist in der Praxis am schwierigsten: Das Token stellt Ihr SSO nach der Anmeldung aus, und man beschafft es sich über eine eigene OIDC-Integration (Authorization-Code-Flow + PKCE) oder mit Werkzeugen wie oidc-agent. Im WebDisk-Dienst müssen Sie nichts davon tun – das Self-Service-Panel meldet Sie per SSO an und führt den gesamten Austausch für Sie durch (dazu im nächsten Abschnitt); die folgenden Beispiele zeigen, was unter der Haube passiert, und sind ein Ausgangspunkt für Integratoren.

Der Austausch des Tokens gegen Zugangsdaten in der aws CLI:

aws sts assume-role-with-web-identity \
  --role-arn "arn:aws:iam::<konto>:role/firma-s3" \
  --role-session-name "jkowalski" \
  --web-identity-token file://id_token.jwt \
  --duration-seconds 3600 \
  --endpoint-url https://s3.twoj-dostawca.example

Als Antwort erhalten Sie einen Block Credentials mit dem Zugangsdaten-Trio und dem Ablaufdatum. Setzen Sie diese in Umgebungsvariablen – und ab diesem Moment funktioniert jedes S3-kompatible Werkzeug wie gewohnt:

export AWS_ACCESS_KEY_ID="ASIA...temporaer"
export AWS_SECRET_ACCESS_KEY="...temporaeres-geheimnis..."
export AWS_SESSION_TOKEN="...langes-session-token..."

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

Noch bequemer: Die AWS CLI und SDKs kennen die Variablen AWS_ROLE_ARN und AWS_WEB_IDENTITY_TOKEN_FILE. Wenn Sie diese setzen, erfolgen Token-Austausch und Aktualisierung der Zugangsdaten automatisch – das Werkzeug ruft STS von selbst auf, wenn der vorherige Ausweis abläuft:

export AWS_ROLE_ARN="arn:aws:iam::<konto>:role/firma-s3"
export AWS_WEB_IDENTITY_TOKEN_FILE="$HOME/.config/firma/id_token.jwt"
export AWS_ENDPOINT_URL_STS="https://s3.twoj-dostawca.example" # ohne dies ruft die CLI Amazons STS auf!

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

Zwei Fallstricke, die man kennen muss:

• --endpoint-url betrifft nur den S3-Aufruf selbst. Der automatische Token-Austausch ist ein separater, versteckter STS-Aufruf – ohne Angabe des Endpoints richtet das Werkzeug ihn an Amazons Standard-STS (sts.<region>.amazonaws.com): Das Beispiel endet mit einem Fehler, und Ihr firmeneigenes id_token landet bei einem fremden Dienst. Setzen Sie deshalb bei einem externen Anbieter immer auch AWS_ENDPOINT_URL_STS (bei Anbietern auf Ceph RGW, uns eingeschlossen, leben S3 und STS unter derselben Adresse). Dies erfordert aktuelle Werkzeuge mit Unterstützung für Endpoints pro Dienst: aws CLI v2 ≥ 2.13 (v1 ≥ 1.29), boto3 ≥ 1.28; ältere SDKs kennen diese Konfiguration nicht. Explizite Aufrufe – wie das erste Beispiel oben – sind unabhängig von der Version korrekt.
• Die Automatik ist nur so frisch wie das Token in der Datei. Bei jeder Aktualisierung liest das Werkzeug die Token-Datei neu ein – und OIDC-id_tokens leben kurz (typischerweise einige bis einige Dutzend Minuten), meist kürzer als der auf ihrer Basis ausgestellte Ausweis. Mit einem manuell gespeicherten Token gelingt die Aktualisierung also ein- bis zweimal, danach antwortet STS mit dem Fehler ExpiredToken. Für Arbeiten, die länger dauern als die Lebensdauer des Tokens, brauchen Sie etwas, das das Token selbst erneuert: eine OIDC-Integration mit Refresh Token, eine erneute Anmeldung – oder eine Umgebung, die die Datei für Sie rotiert (so funktioniert z. B. Kubernetes, wo das kubelet das Service-Token des Pods regelmäßig austauscht).

Dasselbe programmatisch in Python (boto3):

import boto3

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

resp = sts.assume_role_with_web_identity(
    RoleArn="arn:aws:iam::<konto>:role/firma-s3",
    RoleSessionName="jkowalski",
    WebIdentityToken=open("id_token.jwt").read(),
    DurationSeconds=3600,
)
c = resp["Credentials"]

s3 = boto3.client(
    "s3", endpoint_url="https://s3.twoj-dostawca.example",
    aws_access_key_id=c["AccessKeyId"],
    aws_secret_access_key=c["SecretAccessKey"],
    aws_session_token=c["SessionToken"],
)
listing = s3.list_objects_v2(Bucket="firma-dokumenty")
print([o["Key"] for o in listing.get("Contents", [])])

Und wenn Sie rclone bevorzugen: Temporäre Zugangsdaten geben Sie wie gewöhnliche an und ergänzen das Session Token (session_token in der Konfiguration des S3-Remotes oder env_auth = true, damit rclone die drei oben gezeigten Umgebungsvariablen liest).

Was bringt STS mit SSO – und was löst es nicht?

Die ehrliche Bilanz sieht so aus:

Sie gewinnen:

• Keine ewigen Geheimnisse. Es gibt nichts, was man für Jahre in ein Repository einfügen könnte; ein Leak der Zugangsdaten ist eine Stunde lang gefährlich, nicht ein Jahrzehnt.
• Zentrales Offboarding. Das Sperren des Kontos im SSO kappt die Möglichkeit, neue Zugangsdaten zu beziehen – für alle Systeme auf einmal, an einem einzigen Ort.
• Nachvollziehbarkeit. Jede Sitzung hat einen Namen, der mit einer Person verknüpft ist (sofern der Broker oder die Richtlinie ihn erzwingt); das Ereignisprotokoll ist nicht länger anonym.
• Grenzen werden per Richtlinie gesetzt, nicht per Schlüssel. Eine Berechtigungsänderung ist eine Bearbeitung der Rollenrichtlinie – sofort wirksam für alle folgenden Sitzungen, ohne Austausch von Geheimnissen.

Das müssen Sie wissen:

• Ein ausgestellter Ausweis lebt bis zum Ende seiner Gültigkeit. Das Sperren des Kontos im SSO macht Zugangsdaten, die eine Minute zuvor ausgestellt wurden, nicht ungültig – sie laufen von selbst ab, funktionieren aber bis dahin. Genau deshalb setzt man eine kurze Lebensdauer an: eine Stunde, keinen Tag.
• Die Werkzeuge müssen sich aktualisieren können. Ein Skript, das länger läuft als die Gültigkeit der Zugangsdaten, muss diese erneuern – die Automatik mit AWS_WEB_IDENTITY_TOKEN_FILE erledigt das für Sie, vorausgesetzt, in der Datei liegt ein frisches id_token (siehe Fallstricke oben).
• Automaten sind eine andere Geschichte. STS mit SSO löst das Problem der Menschen. Service-Prozesse (Backup, Integrationen) melden sich nicht mit Passwort und MFA an – für sie gibt es eigene Mechanismen: Service-Konten mit minimalen Berechtigungen, Maschinenidentitäten, und statische Schlüssel, sofern sie existieren müssen, werden in einem Secret-Manager aufbewahrt und automatisch rotiert.

Wie wir es bei WebDisk machen: Tenant Manager

Alles, was wir oben beschrieben haben, vereinen wir zu einem Ganzen in unserem Dienst S3 für Organisationen, verwaltet durch den WebDisk Tenant Manager. Bei seiner Konzeption haben wir eine Entscheidung getroffen, die das gesamte Sicherheitsmodell ordnet: Endbenutzer haben überhaupt keine statischen S3-Schlüssel – der Zugriff erfolgt ausschließlich über STS.

Jede Organisation (Tenant) erhält ein Komplettpaket:

• ein eigenes Identitätsverzeichnis – einen abgetrennten Bereich in unserem SSO, in dem der Administrator der Organisation selbst Konten für seine Leute anlegt; hier findet die Anmeldung statt und hier werden die Konten ausscheidender Mitarbeiter gesperrt,
• ein hart isoliertes Konto auf der Ceph-Plattform – Buckets, Rollen und Richtlinien einer Organisation sind für andere unsichtbar und unzugänglich; abgerundet wird die Isolation durch ein dediziertes Präfix für Bucket-Namen,
• IAM-Rollen mit Vertrauen ausschließlich zum Verzeichnis dieser Organisation – die Vertrauensrichtlinie benennt einen konkreten OIDC-Aussteller, sodass ein Token aus dem Verzeichnis eines anderen Unternehmens wertlos ist,
• einen grafischen Editor für IAM-Richtlinien – der Administrator der Organisation verwaltet Berechtigungen über das Panel, ohne JSON von Hand zu schreiben,
• sowie einen eigenen SSE-KMS-Verschlüsselungsschlüssel – ruhende Daten werden mit dem Schlüssel der Organisation verschlüsselt, der sich über das Panel rotieren oder deaktivieren lässt (über die Verschlüsselungsvarianten in S3 haben wir im vorherigen Artikel dieser Reihe geschrieben).

Für den Mitarbeiter der Organisation sieht das so aus: Er ruft die Self-Service-Seite auf, meldet sich mit seinem Firmenkonto an (dem SSO der Organisation), und das Panel – als Broker agierend – führt für ihn das oben beschriebene AssumeRoleWithWebIdentity aus und zeigt fertige, eine Stunde gültige Zugangsdaten samt fertigen Konfigurationsfragmenten zum Einfügen: Umgebungsvariablen, Konfiguration für die aws CLI, Konfiguration für rclone. Der Broker vergibt auch den Sitzungsnamen auf Basis der angemeldeten Identität – die Nachvollziehbarkeit hängt also nicht vom guten Willen des Aufrufers ab. Ein Klick erneuert den Ausweis. Null Schlüssel zum Merken, null Geheimnisse zum Rotieren, volle Kompatibilität mit jedem S3-Werkzeug.

Der Dienst S3 für Organisationen befindet sich derzeit in der Early-Access-Phase – wenn Sie dieses Modell bei sich testen möchten, schreiben Sie uns, und wir bereiten eine Umgebung für Ihre Organisation vor.

Der Unterschied zu unseren Endanwendungen ist hervorzuheben. In den Webanwendungen WebDisk Files oder WebDisk Send berühren Sie S3-Zugangsdaten gar nicht — den Zugriff auf den Speicher verwaltet die Anwendung für Sie. Das STS-Angebot ist für die umgekehrte Situation: wenn Ihre Leute und Ihre eigenen Werkzeuge direkt mit S3 sprechen sollen – Analyseskripte, rclone, Integrationen – und Sie möchten, dass sie das mit Ihrer Unternehmensidentität tun und nicht mit einem Phantomschlüssel aus dem Notizbuch.

Häufige Fragen

Worin unterscheidet sich STS von statischen S3-Schlüsseln? Ein statisches Schlüsselpaar funktioniert unbegrenzt und lebt losgelöst von der Identität eines Menschen – es wird geleakt, nicht rotiert, und die Sperrung des Kontos im Unternehmensverzeichnis macht es nicht ungültig. STS stellt stattdessen ein Trio temporärer Zugangsdaten aus (Access Key, Secret Key und Session Token) mit einem Ablaufdatum – danach werden sie wertlos. Für die Werkzeuge sehen sie aus und funktionieren wie gewöhnliche S3-Schlüssel.

Muss ich für die Nutzung von STS meine Werkzeuge wechseln? Nein. Temporäre Zugangsdaten sind gewöhnliche S3-Zugangsdaten plus Session Token — sie werden von der aws CLI, allen SDKs, rclone und praktisch jedem S3-kompatiblen Werkzeug unterstützt. Es ändert sich nur die Art, wie man sie bezieht.

Was passiert, wenn ein Mitarbeiter das Unternehmen verlässt? Der Administrator sperrt sein Konto im Verzeichnis (SSO) – und damit endet die Prozedur. Neue Zugangsdaten kann er nicht mehr beziehen. Der zuletzt ausgestellte Ausweis läuft spätestens nach einer Stunde von selbst ab.

Funktioniert STS nur in AWS? Nein – es ist eine von AWS definierte API, die zum De-facto-Standard geworden ist und auch von anderen Plattformen implementiert wird, darunter Ceph RGW – die Basis für unsere Object-Storage-Plattform. Aus Sicht der Werkzeuge gibt es keinen Unterschied: dieselben Aufrufe, dasselbe Format der Zugangsdaten.

Worin unterscheidet sich AssumeRole von AssumeRoleWithWebIdentity? AssumeRole verlangt, dass der Aufrufer bereits über irgendwelche Zugangsdaten verfügt (einen Schlüssel oder eine andere Rolle) – es dient dem Wechsel zwischen Rollen. AssumeRoleWithWebIdentity authentifiziert allein mit dem OIDC-Token aus dem SSO – und ist deshalb die richtige Wahl, wenn der Ausgangspunkt ein Firmenkonto ist und kein vorhandener Schlüssel.

Ist eine Stunde Gültigkeit nicht zu kurz? In der Praxis nicht: Neue Zugangsdaten beschafft man sich mit einem Klick im Panel (oder automatisch, wenn Ihre OIDC-Integration für ein frisches id_token in der Datei sorgt), und die kurze Gültigkeit ist genau das, was ein Leak wenig gefährlich macht. Das ist ein bewusster Kompromiss – je länger der Ausweis gilt, desto länger funktioniert er in den falschen Händen.

Ich habe Automaten und Service-Prozesse. Können auch sie STS verwenden? Die Aufrufe selbst – ja, aber ein Automat meldet sich nicht mit Passwort und MFA an, er braucht also eine andere Identitätsquelle. Das ist ein eigenes Thema (Maschinenidentitäten, Service-Konten); in einer typischen Implementierung nutzen Menschen SSO + STS, während die wenigen Service-Konten minimale Berechtigungen haben und ihre Schlüssel in der Obhut eines Secret-Managers liegen.

Fazit

Statische S3-Schlüssel sind Sicherheitsschulden, die mit jedem Monat wachsen: Geheimnisse vermehren sich, das Wissen über sie geht verloren, und das Ausscheiden von Mitarbeitern ändert nichts. STS kehrt dieses Modell um – Zugangsdaten werden kurzlebig, personengebunden und auf Basis der Unternehmensanmeldung ausgestellt:

• SSO sagt, wer Sie sind (und erlaubt es, dieses Konto zentral zu sperren),
• die IAM-Rolle sagt, was Sie dürfen (und erlaubt es, das mit einer einzigen Richtlinie zu ändern),
• STS tauscht das eine gegen das andere – für eine Stunde, nicht für immer.

Bei WebDisk haben wir daraus das Fundament des Dienstes S3 für Organisationen gemacht: ein eigenes Identitätsverzeichnis, harte Isolation, ein Richtlinien-Editor und Self-Service-Zugangsdaten auf Zeit – ohne einen einzigen statischen Schlüssel in den Händen der Benutzer. Der Dienst befindet sich in der Early-Access-Phase – wenn Sie dieses Modell bei sich sehen möchten, schreiben Sie uns. Und wenn Sie interessiert, wie wir ruhende Daten verschlüsseln, werfen Sie einen Blick in den vorherigen Artikel der Reihe über SSE-S3, SSE-KMS und SSE-C.

Dieser Artikel ist Teil einer Reihe über Datensicherheit in den WebDisk-Diensten. Die Beispiele führen Sie auf jeder S3-Plattform mit STS- und OIDC-Unterstützung aus. Der Parameter --endpoint-url in der aws CLI verweist auf den S3-Endpoint Ihres Anbieters, und beim automatischen Token-Austausch verweist zusätzlich AWS_ENDPOINT_URL_STS auf dessen STS-Endpoint – in Ceph RGW leben beide APIs unter einer Adresse, in AWS sind es zwei verschiedene Dienste.