Sicheres Teilen von Links für Entwickler

In der Entwicklung taucht das Teilen von Geheimnissen meist an drei Stellen auf: beim Onboarding, bei der Übergabe an Dienstleister und bei der Reaktion auf Sicherheitsvorfälle. Dieser Artikel zeigt aus Sicht von Entwicklern, wann ein Einmal-Link passt, wann nicht, und wie Sie ihn per Skript erzeugen, ohne das Geheimnis dabei in Ihre Shell-History zu schreiben. Wer das Prinzip erst ausprobieren will: Der kostenlose Generator für Einmal-Links funktioniert ohne Konto.

Wann sollten Entwickler einen Einmal-Link nutzen?

Wenn an mindestens einem Ende der Übergabe ein Mensch steht und der Wert danach nirgends mehr liegen soll. Die typischen Fälle:

• Neue Teammitglieder in der Entwicklung bekommen ihre ersten Zugangsdaten.
• Während eines Vorfalls wird ein temporäres Admin-Passwort geteilt.
• Ein Token für einen Dienstleister oder Freelancer soll nicht in Ihrem Tresor landen.
• Zugangsdaten werden erneuert, und der alte Wert soll schnell ungültig werden.
• Ein Kunde bekommt den API-Schlüssel, den Sie für ihn angelegt haben.

Wann Sie keinen Einmal-Link nutzen sollten

• Geheimnisse zwischen Maschinen. CI-Umgebungsvariablen (zum Beispiel GitHub Actions secrets), Kubernetes Secrets und dynamische Zugangsdaten aus Vault sind dort das richtige Mittel. Ein Link dient der Übergabe von Mensch zu Mensch, mit der die Werte in diese Systeme gelangen.
• Langlebige Team-Zugangsdaten. Die gehören in einen Passwortmanager.
• Öffentliche Konfiguration. Verkleiden Sie keine harmlose Konfiguration als Geheimnis. Nutzen Sie einen normalen Link.

Die Trennlinie: Sind beide Enden der Übertragung Maschinen, nutzen Sie den Secret Store Ihrer Plattform. Steht an mindestens einem Ende ein Mensch, ist ein Einmal-Link meist das sauberste Mittel.

Per Skript erzeugen

LinkPilot hat eine REST-API in jedem Tarif, auch im Free-Tarif (die Rate-Limits unterscheiden sich je nach Tarif). Ein Geheimnis aus einem Skript heraus anzulegen, sieht so aus:

LP_KEY=lp_live_...

URL=$(curl -sS https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "payload": "'"$NEW_DB_PASSWORD"'",
    "expires_in": 3600,
    "burn_after_read": true,
    "passphrase": "'"$ONBOARDING_PASSPHRASE"'"
  }' | jq -r '.url')

echo "Secret link: $URL"

Diese URL leiten Sie in den Zustellkanal weiter, den Sie ohnehin nutzen: Slack-Direktnachricht, E-Mail oder den Webhook Ihres Onboarding-Tools.

Den Inhalt aus der Prozessliste heraushalten

Das Beispiel oben hat einen klassischen Fehler: Wird der Inhalt in -d eingesetzt, steht er in der Kommandozeile von curl, und jeder lokale Benutzer kann ihn mit ps lesen, solange die Anfrage läuft. Bauen Sie das JSON stattdessen mit jq und übergeben Sie es mit curls -d @- über stdin:

set -euo pipefail

jq -n --arg payload "$NEW_DB_PASSWORD" \
      --arg pass "$ONBOARDING_PASSPHRASE" \
      '{payload: $payload, expires_in: 3600,
        burn_after_read: true, passphrase: $pass}' |
curl -sS https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -H "Content-Type: application/json" \
  -d @- | jq -r '.url'

Drei Gewohnheiten, die zum Reflex werden sollten:

• Werte kommen aus Umgebungsvariablen oder der CLI eines Secrets-Managers. Tippen Sie sie nie in eine interaktive Shell, wo sie in der History landen.
• Das Skript gibt den Link aus, nie den Inhalt.
• set -euo pipefail, damit ein fehlgeschlagener API-Aufruf nicht unbemerkt eine leere URL an den nächsten Schritt weitergibt.

Vorlage für das Onboarding

Ein Ablauf, der sich am ersten Tag neuer Entwickler bewährt:

1. Das Onboarding-Skript legt Konten an und holt einmalige Zugangsdaten.
2. Das Skript erstellt pro Zugang einen Secret-Link mit Ablauf nach 4 Stunden und einer gemeinsamen Passphrase.
3. Das Skript schickt eine E-Mail mit allen Links und eine Slack-Direktnachricht mit der Passphrase.
4. Die neue Person öffnet jeden Link und kopiert die Zugangsdaten in ihren Passwortmanager.
5. Was bis Feierabend ungelesen ist, wird widerrufen und in ihrem Tempo neu ausgestellt.

Warum diese Einstellungen: Der Ablauf nach 4 Stunden deckt einen normalen ersten Vormittag ab, ohne dass Zugangsdaten über Nacht gültig bleiben. Die Passphrase kommt über einen zweiten Kanal, sodass eine weitergeleitete oder falsch zugestellte E-Mail keinen Schaden anrichtet. Durch das Löschen nach dem Lesen enthält das Postfach abends nur noch tote URLs.

Sagen Sie der neuen Person ausdrücklich: „Jeder Link funktioniert nur einmal. Speichern Sie den Wert in Ihrem Passwortmanager, bevor Sie den Tab schließen.“ Der häufigste Fehler beim Onboarding: Jemand liest das Geheimnis, schließt den Tab und geht davon aus, später noch einmal nachsehen zu können.

Ablaufplan für einen Passwortwechsel

So erneuern Sie ein geteiltes Datenbank-Passwort, wenn ein Freelancer oder ein Teammitglied den neuen Wert bekommen soll:

1. Erzeugen Sie das neue Passwort und setzen Sie es im Quellsystem (Datenbank, Cloud-Konsole oder wo immer es maßgeblich ist).
2. Aktualisieren Sie zuerst Ihre eigenen Systeme, die den Wert nutzen (CI-Tresor, K8s-Secret, App-Konfiguration), damit nichts ausfällt, während die Übergabe an den Menschen läuft.
3. Erstellen Sie einen Einmal-Link für den neuen Wert: Löschen nach dem Lesen, Ablauf nach 1 Stunde, Passphrase.
4. Schicken Sie Link und Passphrase über verschiedene Kanäle.
5. Prüfen Sie das Abruf-Ereignis im Audit-Verlauf. Kein Abruf vor dem Ablauf? Widerrufen und neu ausstellen. Schicken Sie nie denselben Link noch einmal.
6. Bestätigen Sie, dass die alten Zugangsdaten an der Quelle deaktiviert sind.

Jeder Passwortwechsel bekommt einen eigenen Link. Links sind bewusst unabhängig voneinander. Für die Zustellung ist das ein Vorteil, für die Verwaltung bringt es nichts. Der Zeitplan für Passwortwechsel gehört deshalb in Ihren Manager oder Ihr Runbook, nicht in das Link-Tool.

Reaktion auf Sicherheitsvorfälle

Während eines Vorfalls müssen Sie oft Zugangsdaten erneuern und die neuen schnell an einige Beteiligte verteilen. Fügen Sie sie nicht in den Vorfall-Kanal ein. Dieser Kanal wird für die Nachbesprechung aufgezeichnet, und das Geheimnis landet im Export, im Retro-Dokument und in jedem Archivsystem, das daran hängt.

• Erneuern Sie die Zugangsdaten im Quellsystem.
• Erstellen Sie einen Secret-Link mit Ablauf nach 30 Minuten.
• Posten Sie den Link im Kanal und schicken Sie die Passphrase per Direktnachricht.
• Bestätigen Sie nach dem Vorfall, dass der Link gelöscht oder widerrufen ist.

In der Nachbesprechung steht dann eine tote URL statt eines gültigen Admin-Passworts. Der Audit-Verlauf liefert der Person, die die Zeitleiste prüft, nebenbei einen exakten Eintrag wie „Zugangsdaten um 14:32 neu ausgestellt, um 14:33 gelesen“.

Ein Hinweis zu Link-Vorschauen: Chat-Clients rufen eingefügte URLs ab, um eine Vorschau anzuzeigen. Ein gut gebauter Secret-Link übersteht das, weil der Abruf für die Vorschau ein GET ist und das Öffnen ein ausdrücklicher POST. Die genaue Funktionsweise steht im Artikel Link-Scanner und Einmal-Geheimnisse. Wenn Sie ein Tool prüfen, testen Sie das vor einem Vorfall, nicht währenddessen.

Was verrät der Audit-Verlauf?

Ob ein Geheimnis gelesen wurde, wann und ungefähr von wo, und ob jemand eine falsche Passphrase versucht hat. Jedes Geheimnis in LinkPilot hat einen Ereignisverlauf: created, viewed, failed_passphrase, burned, expired, revoked. Abrufe werden mit Zeitstempel, grober Standortangabe (falls verfügbar), User-Agent und gehashter IP-Adresse gespeichert (SHA-256 mit täglich wechselndem Salt; die unveränderte IP-Adresse wird nie gespeichert). In der Praxis liefert das drei Antworten, auf die sich Skripte und Runbooks verlassen können:

• Zustellbestätigung: Ein viewed-Ereignis bedeutet, dass die Übergabe stattgefunden hat.
• Erkennung von Auffälligkeiten: Eine Häufung von failed_passphrase oder ein Abruf, den Sie nicht zuordnen können, ist das Signal, die Zugangsdaten sofort zu erneuern.
• Ein sauberer Nachweis für Prüfungen: „Einmal zugestellt, einmal gelesen, gelöscht“ ist ein Satz, den Auditoren gern lesen.

Grenzen: was Links nicht lösen

• Sie sind kein Tresor. Ein Einmal-Link verwaltet weder laufende Zugriffe noch Zeitpläne für Passwortwechsel oder Übersichten, wer was hat.
• Der Link ist der Schlüssel. LinkPilot verschlüsselt Texte in Ihrem Browser und erhält den Schlüssel nie. Dieser Schlüssel steckt aber im Teil des Links nach dem #. Wer den vollständigen Link hat, kann das Geheimnis also lesen, und ist der Link verloren, lässt sich das Geheimnis nicht wiederherstellen. Angehängte Dateien werden genauso verschlüsselt, ihre Namen und Größen jedoch nicht. Ein kurzer Ablauf und das Löschen nach dem Lesen bleiben deshalb wichtig. Aktualisierung vom 29. September 2026: Dieser Punkt lautete früher „Sie sind nicht Ende-zu-Ende-verschlüsselt“. Das traf bis zu diesem Datum zu. Details stehen auf der Seite zur Sicherheitsarchitektur.
• Sie beheben keine verstreuten Geheimnisse im Code. Schlüssel, die fest in Repositories stehen, brauchen Scanning und Erneuerung, keinen besseren Zustellweg.
• Sie schützen nicht das andere Ende. Hat ein Mensch den Wert gelesen, gehen Sie davon aus, dass er überall dort existiert, wo diese Person ihn abgelegt hat.

Weiterlesen

• API-Schlüssel sicher teilen
• Ablaufende Links: Warum kurze Fristen wichtig sind
• Sicherheitsarchitektur von LinkPilot

Quellen

• GitHub Docs, Using secrets in GitHub Actions.
• Kubernetes, Secrets.
• jq, Manual.
• curl, Manual page, -d, --data.