API-Schlüssel sicher teilen

Fügen Sie einen API-Schlüssel nie in einen Chat oder eine E-Mail ein. Senden Sie ihn als Einmal-Link: Der Schlüssel wird in Ihrem Browser verschlüsselt, der Entschlüsselungsschlüssel bleibt im Teil des Links nach dem #, und die gespeicherte Kopie wird nach einmaligem Öffnen gelöscht. Rotieren Sie danach jeden Schlüssel, der bereits im Klartext eingefügt wurde.

Der Rest dieses Leitfadens liefert die Details: warum die naheliegenden Kanäle versagen, wie die Übergabe genau abläuft, was zu tun ist, wenn ein Schlüssel trotzdem durchsickert, und in welchen Fällen ein Einmal-Link das falsche Werkzeug ist.

Warum ist es unsicher, einen API-Schlüssel per Slack oder E-Mail zu senden?

Weil beide die Nachricht so lange aufbewahren, wie irgendetwas sie speichert, und sie unterwegs auf jedes Gerät und in jeden Export kopieren.

• Beide sind für immer durchsuchbar. Ein Schlüssel, der 2023 geteilt wurde, ist der Schlüssel, mit dem Ihr nächster Sicherheitsvorfall beginnt. Angreifer, die in einen Firmenchat oder ein Postfach gelangen, suchen dort routinemäßig nach genau den Zeichenfolgen, die typisch für API-Schlüssel sind: sk_live, AKIA, ghp_, Bearer.
• Beide synchronisieren überallhin. Handys, private Laptops, Tablets: Geräte, die Ihre Sicherheitskontrollen nicht erfassen und die Ihre Richtlinie zum Löschen aus der Ferne nicht erreicht.
• Beide werden exportiert. Compliance-Prüfungen, rechtliche Beweisanforderungen und Workspace-Exporte erzeugen Kopien des Verlaufs. Jeder Export ist ein weiterer Ort, an dem der Schlüssel liegt.
• Beide überdauern das Ausscheiden. Der Auftrag des externen Dienstleisters endet, der Direktnachrichten-Verlauf mit Ihrem Stripe-Schlüssel darin nicht.

Wer eine vertrauliche Information in eines dieser Tools schreibt, nimmt hin, dass sie überall dort liegt, wo die Nachricht landet, und zwar so lange, wie irgendetwas sie aufbewahrt. Keines der beiden Systeme wurde zum Vergessen gebaut.

Vor dem Teilen: den Schlüssel verkleinern

Die beste Übergabe ist eine, bei der es auf den übergebenen Schlüssel kaum ankommt. Wenden Sie deshalb schon an der Quelle das Prinzip der minimalen Rechte an, bevor Sie irgendetwas erzeugen:

• Schränken Sie den Umfang ein. Eingeschränkte Schlüssel bei Stripe, Fine-grained Personal Access Tokens bei GitHub, AWS-IAM-Richtlinien für bestimmte Aktionen und Ressourcen: Die meisten seriösen Anbieter lassen Sie einen Schlüssel erstellen, der nur genau das kann, was der Empfänger braucht.
• Bevorzugen Sie Lesezugriff, sofern Schreibrechte nicht wirklich nötig sind.
• Legen Sie beim Anbieter einen Ablauf fest, wo die Plattform das unterstützt (Fine-grained PATs bei GitHub, temporäre AWS-Zugangsdaten über STS). Dann hat selbst ein durchgesickerter Schlüssel ein Verfallsdatum, unabhängig von allem, was Sie später tun.
• Benennen Sie ihn nach dem Empfänger (vendor-x-readonly). So ist das Widerrufen in sechs Monaten eine Entscheidung auf einen Blick statt einer archäologischen Ausgrabung.

Ist der Schlüssel eingeschränkt, befristet und nur zum Lesen berechtigt, wird selbst das schlimmste Leck vom Sicherheitsvorfall zum bloßen Ärgernis.

Das Übergabemuster

1. Erzeugen Sie den Schlüssel im Quellsystem (AWS, Stripe, Ihre eigene API) mit den minimal nötigen Berechtigungen, wie oben beschrieben.
2. Fügen Sie ihn in einen Einmal-Link ein, mit aktiviertem Löschen nach dem Lesen und dem kürzesten passenden Ablauf: 1 Stunde ist die kürzeste Voreinstellung, danach folgen 24 Stunden und 7 Tage, mit Pro auch ein frei wählbares Datum mit Uhrzeit. Gerade lang genug für die eigentliche Übergabe, nicht länger.
3. Fügen Sie eine Passphrase hinzu und übermitteln Sie sie über einen anderen Kanal: den Link per E-Mail, die Passphrase per SMS oder Slack-Direktnachricht. In LinkPilot sind Passphrase, frei wählbarer Ablauf und Audit-Verlauf Funktionen des Pro-Tarifs für 29 $ im Monat. Wenn einer der beiden Kanäle kompromittiert wird, hat der Angreifer trotzdem nur die Hälfte des Puzzles. (LinkPilot hasht die Passphrase im Browser mit SHA-256, bevor sie gesendet wird. Die Passphrase im Klartext erreicht nie die Datenbank oder die Logs des Servers, und Versuche sind auf 5 pro IP-Adresse und Minute begrenzt.)
4. Senden Sie den Link.
5. Bestätigen Sie über einen anderen Kanal, dass der Empfänger ihn abgerufen hat, und prüfen Sie den Audit-Verlauf: ein Abruf, zur erwarteten Zeit, vom erwarteten Ort. Das ist Ihre Empfangsbestätigung.

Bleibt der Link bis zum Ablauf ungeöffnet, widerrufen Sie ihn und senden Sie einen neuen. Verlängern Sie ihn nicht und verwenden Sie ihn nicht wieder.

Beispiel: einen eingeschränkten Stripe-Schlüssel weitergeben

# generate a restricted key with the minimum needed scopes
stripe api_keys create \
  --restricted \
  --display-name "vendor-x-readonly"

# pipe the resulting key into a LinkPilot secret
curl -X POST https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -d 'payload=sk_restricted_…' \
  -d 'expires_in=3600' \
  -d 'burn_after_read=true'

Was der Empfänger erlebt: Der Link öffnet eine Seite mit einer Schaltfläche zum Anzeigen, nicht den Schlüssel. Vorschau-Bots und E-Mail-Scanner, die die URL vorab abrufen, erhalten nur Metadaten, denn ein Abruf wird ausschließlich beim ausdrücklichen Klick auf „Anzeigen“ erfasst, nie beim GET. Klickt der Empfänger auf „Anzeigen“ (und gibt die Passphrase ein, falls gesetzt), sieht er den Schlüssel genau einmal. Danach wird der gespeicherte Inhalt überschrieben, und der Link liefert HTTP 410. Selbst wenn die E-Mail im ganzen Unternehmen weitergeleitet wird, konnte nur die erste Person den Schlüssel je lesen. Und der Audit-Verlauf zeigt Ihnen, wer das war.

Welcher Kanal für welche Übergabe

Was tun, wenn ein API-Schlüssel durchgesickert ist?

Betrachten Sie ihn als kompromittiert und rotieren Sie ihn beim Anbieter. Die Nachricht zu löschen bringt nichts. Das gilt für jeden Schlüssel, der in einer Chatnachricht, einem E-Mail-Text, einem Screenshot, einem Git-Commit oder einem öffentlichen Paste gelandet ist. In dieser Reihenfolge:

1. Stellen Sie zuerst den Ersatzschlüssel aus, sofern der Anbieter zwei aktive Schlüssel erlaubt. So vermeiden Sie Ausfälle für die legitimen Nutzer.
2. Widerrufen Sie den durchgesickerten Schlüssel beim Anbieter. Nur dieser Schritt beendet die Gefährdung tatsächlich. Die Slack-Nachricht zu löschen tut das nicht.
3. Übergeben Sie den neuen Schlüssel richtig: Einmal-Link, Passphrase, kurzer Ablauf, wie im Muster oben.
4. Prüfen Sie die Nutzungsprotokolle des Anbieters für den durchgesickerten Schlüssel zwischen dem Leck und dem Widerruf. Unerwartete Aufrufe bedeuten: Jetzt ist es ein Sicherheitsvorfall, keine Aufräumarbeit mehr.
5. Beheben Sie die Ursache des Einfügens: Nehmen Sie den Schlüssel in Ihre per .gitignore ausgeschlossene Env-Konfiguration auf, aktivieren Sie Secret Scanning bei Ihrem Repository-Host, oder ändern Sie das Runbook, das jemanden angewiesen hat, ihn per Direktnachricht zu schicken.

Der ganze Vorgang sollte nur Minuten dauern. Wenn das Rotieren eines Schlüssels so heikel ist, dass Leute es vermeiden, ist diese Zerbrechlichkeit die eigentliche Schwachstelle. Beheben Sie zuerst sie.

Was Sie vermeiden sollten

• Dieselbe vertrauliche Information erneut senden. Rotieren Sie stattdessen. Erneutes Senden zerstört den Nachweis „genau ein Abruf“, der den Einmal-Link überhaupt lohnenswert gemacht hat.
• Lange Ablaufzeiten. Wählen Sie standardmäßig kurze. Die meisten Übergaben sind in Minuten erledigt. Ein Zeitfenster von 8 Stunden ist nur ein längeres Leck.
• Auf die Passphrase verzichten. Sie kostet fast nichts und schützt vor versehentlich weitergegebenen URLs: weitergeleiteten E-Mails, geteilten Bildschirmen, Blicken über die Schulter auf einen gemeinsamen Monitor.
• Screenshots von Schlüsseln. Sie landen in der Fotogalerie, in der Cloud-Synchronisierung von Fotos und in der Bildersuche. Ein Screenshot hat die Dauerhaftigkeit eines Chat-Eintrags, ist für Sie schlechter durchsuchbar und für Texterkennung (OCR) bestens.
• Das Link-Tool als Speicher nutzen. Der Link ist der Kurier, nicht der Tresor. Der Empfänger sollte den Schlüssel sofort nach Erhalt in einem Passwortmanager oder seiner Env-Konfiguration speichern.

Wann ein Einmal-Link das falsche Werkzeug ist

Ehrlich gesagt hat dieses Muster Grenzen:

• Zugangsdaten von Maschine zu Maschine gehören in einen Secrets Manager oder den nativen Speicher der Plattform und werden beim Deployment oder zur Laufzeit eingespielt. Ein Mensch, der auf einen Link klickt, ist kein Deployment-Schritt.
• Langlebige gemeinsame Zugangsdaten gehören in einen Passwortmanager mit echter Zugriffskontrolle und Widerruf pro Person.
• Häufiges Rotieren (Schlüssel, die sich stündlich ändern) sollte durchgehend automatisiert sein. Menschen und Links haben in diesem Ablauf nichts zu suchen.
• Vertrauliche Informationen, die keinerlei Dritte berühren dürfen: Verlegen Sie die Übergabe in die Offline-Welt. Aktualisierung vom 29. September 2026: Dieser Punkt besagte ursprünglich, dass LinkPilot keine Ende-zu-Ende-Verschlüsselung beansprucht, und empfahl stattdessen ein Ende-zu-Ende-verschlüsseltes Tool. LinkPilot verschlüsselt Textinhalte und angehängte Dateien jetzt im Browser und speichert also nur noch Geheimtext. Die Seite zur Sicherheitsarchitektur beschreibt genau, was geschützt ist und was nicht.

Für den Normalfall, eine Person übergibt einer anderen einmal einen Zugang, ist der Einmal-Link mit Passphrase und kurzem Ablauf das stärkste einfache Muster, das es gibt.

Weiterführende Artikel

• Warum URLs vertrauliche Informationen preisgeben
• Passwörter sicher teilen: 5 Methoden im Vergleich
• Sicherheitsarchitektur von LinkPilot
• URL-Shortener-APIs im Vergleich
• Kostenloser Secret-Link-Generator

Quellen

• Stripe Docs, API keys: limit access with restricted keys.
• GitHub Docs, Managing your personal access tokens.
• AWS IAM User Guide, Temporary security credentials in IAM.