Sikker deling af links for udviklere

For en udvikler dukker deling af hemmeligheder som regel op tre steder: onboarding, overdragelse til leverandører og hændelseshåndtering. Her er en udviklers syn på, hvornår du skal bruge et engangslink, hvornår du skal lade være, og hvordan du opretter det fra et script uden at lække hemmeligheden til din shellhistorik undervejs. Vil du prøve mekanismen først, kræver den gratis generator til hemmelige engangslinks ingen konto.

Hvornår skal en udvikler bruge et engangslink?

Når der er et menneske i mindst den ene ende af overdragelsen, og værdien ikke må ligge nogen steder bagefter. De typiske tilfælde:

• Onboarding af en ny udvikler med de første loginoplysninger.
• Deling af en midlertidig administratoradgangskode under en hændelse.
• Levering af et token til en leverandør eller konsulent, som ikke skal ligge i din boks.
• Skift af loginoplysninger, hvor den gamle værdi hurtigt skal holde op med at virke.
• Afsendelse af den API-nøgle, du har oprettet til en kunde.

Hvornår du ikke skal bruge et engangslink

• Hemmeligheder fra maskine til maskine. Miljøvariabler i CI (fx GitHub Actions secrets), Kubernetes Secrets og dynamiske loginoplysninger fra Vault er den rigtige byggesten her. Et link er til overdragelsen fra et menneske ind i de systemer.
• Langlivede loginoplysninger til teamet. De hører hjemme i en adgangskodeadministrator.
• Offentlig konfiguration. Lad være med at klæde konfiguration, der ikke er hemmelig, ud som en hemmelighed. Brug et almindeligt link.

Skillelinjen: Er begge ender af overførslen maskiner, bruger du platformens lager til hemmeligheder. Er mindst den ene ende et menneske, er et engangslink som regel den reneste byggesten.

Opret det fra et script

LinkPilot har et REST-API (på alle planer, også Free). Sådan ser det ud, når et script opretter en hemmelighed:

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"

Send URL'en videre til den kanal, du allerede bruger: en direkte besked i Slack, en e-mail eller dit onboardingværktøjs webhook.

Hold indholdet ude af proceslisten

Eksemplet ovenfor har en klassisk fejl: Når indholdet indsættes i -d, havner det på curls kommandolinje, hvor alle lokale brugere kan læse det via ps, mens kaldet kører. Byg i stedet JSON'en med jq, og send den via stdin med curls -d @-:

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'

Tre vaner, der bør sidde på rygraden:

• Værdierne kommer fra miljøvariabler eller CLI'en til et lager til hemmeligheder, aldrig fra en interaktiv shell, hvor de ender i historikken.
• Scriptet udskriver linket, aldrig indholdet.
• set -euo pipefail, så et mislykket API-kald ikke i stilhed kan give en tom URL videre til næste trin.

Skabelon til onboarding

Et mønster, der virker godt for nye udviklere på første dag:

1. Onboardingscriptet opretter konti og henter loginoplysninger til engangsbrug.
2. Scriptet opretter et hemmeligt link for hvert sæt loginoplysninger med udløb efter 4 timer og en fælles adgangssætning.
3. Scriptet sender en e-mail med alle linkene og en direkte besked i Slack med adgangssætningen.
4. Udvikleren åbner hvert link og kopierer loginoplysningerne over i sin adgangskodeadministrator.
5. Alt, der ikke er læst ved arbejdsdagens slutning, bliver tilbagekaldt og sendt igen i udviklerens eget tempo.

Derfor disse indstillinger: Udløbet på 4 timer dækker en normal første formiddag, uden at loginoplysningerne er aktive natten over. Adgangssætningen sendes via en anden kanal, så en videresendt eller fejlleveret e-mail er harmløs. Fordi linkene slettes efter læsning, indeholder udviklerens indbakke kun døde URL'er, når dagen er slut.

Sig det tydeligt til den nyansatte: ”Hvert link virker kun én gang. Gem værdien i din adgangskodeadministrator, før du lukker fanen.” Den mest almindelige fejl ved onboarding er en modtager, der læser hemmeligheden, lukker fanen og regner med at kunne vende tilbage senere.

En drejebog for skift

Sådan skifter du en delt databaseadgangskode, når en konsulent eller kollega er modtager:

1. Opret den nye adgangskode, og tag den i brug i kildesystemet (databasen, cloudkonsollen eller der, hvor den autoritative værdi ligger).
2. Opdater dine egne forbrugere først (CI-boksen, K8s secret, appkonfigurationen), så intet går i stykker, mens overdragelsen til mennesket foregår.
3. Opret et engangslink til den nye værdi: slettes efter læsning, udløber efter 1 time, med adgangssætning.
4. Lever link og adgangssætning via forskellige kanaler.
5. Tjek viewed-hændelsen i revisionsloggen. Ingen visning før udløbet? Tilbagekald linket, og opret et nyt. Send aldrig det samme link igen.
6. Bekræft, at de gamle loginoplysninger er deaktiveret ved kilden.

Hvert skift får sit eget link. Links er uafhængige af hinanden med vilje. Det er en fordel ved levering og en mangel ved styring, så planen for skift hører hjemme i din adgangskodeadministrator eller drejebog, ikke i linkværktøjet.

Hændelseshåndtering

Under en hændelse skal du ofte skifte loginoplysninger og hurtigt give de nye til et par af dem, der håndterer hændelsen. Indsæt dem ikke i hændelseskanalen. Kanalen bliver gemt til evalueringen, og hemmeligheden ender i eksporten, i evalueringsdokumentet og i alle de arkivsystemer, der ligger efter dem.

• Skift loginoplysningerne i kildesystemet.
• Opret et hemmeligt link, der udløber efter 30 minutter.
• Læg linket i kanalen, og send adgangssætningen som direkte besked.
• Bekræft efter hændelsen, at linket er slettet eller tilbagekaldt.

Evalueringen indeholder så en død URL i stedet for en aktiv administratoradgangskode, og revisionsloggen giver den, der gennemgår tidslinjen, en præcis registrering, ”loginoplysninger udstedt igen kl. 14:32, læst kl. 14:33”, helt gratis.

En bemærkning om forhåndsvisninger: Chatprogrammer henter indsatte URL'er for at vise en forhåndsvisning. Et veludformet hemmeligt link overlever det, fordi forhåndsvisningen er et GET, mens visningen af hemmeligheden er et eksplicit POST. Se linkscannere og engangshemmeligheder for hele mekanikken. Hvis du vurderer et værktøj, så test det før en hændelse, ikke under den.

Hvad fortæller revisionsloggen dig?

Om en hemmelighed er læst, hvornår og nogenlunde hvorfra, og om nogen har prøvet en forkert adgangssætning. Hver hemmelighed i LinkPilot har en tidslinje med hændelser: created, viewed, failed_passphrase, burned, expired, revoked. Visninger registreres med tidsstempel, grov geolokation, når den er tilgængelig, brugeragent og en hashet IP-adresse (SHA-256 med et salt, der skiftes dagligt; den rå IP-adresse gemmes aldrig). I praksis giver det tre svar, som scripts og drejebøger kan regne med:

• Leveringsbekræftelse. En viewed-hændelse betyder, at overdragelsen er sket.
• Opdagelse af afvigelser. En række failed_passphrase-hændelser eller en visning, du ikke genkender, er dit signal til at skifte med det samme.
• En ren registrering til gennemgange. ”Leveret én gang, læst én gang, slettet” er en sætning, revisorer kan lide.

Begrænsninger: hvad links ikke løser

• De er ikke en boks. Et engangslink styrer ikke løbende adgang, planer for skift eller overblik over, hvem der har hvad.
• Linket er nøglen. LinkPilot krypterer tekstindhold i din browser og modtager aldrig nøglen, men nøglen rejser i den del af URL'en, der står efter #. Alle, der får fat i hele linket, kan derfor læse hemmeligheden, og går linket tabt, kan hemmeligheden ikke gendannes. Vedhæftede filer krypteres på samme måde, men deres navne og størrelser krypteres ikke. Kort udløb og sletning efter læsning betyder stadig noget. Opdatering den 29. september 2026: Dette punkt sagde tidligere ”de er ikke end-to-end-krypterede”, hvilket var korrekt indtil den dato. Detaljerne står på siden om sikkerhedsarkitektur.
• De løser ikke spredning af hemmeligheder i koden. Nøgler, der er hardcodet i repos, kræver scanning og skift, ikke en bedre leveringsmetode.
• De kan ikke beskytte den anden ende. Når et menneske har læst værdien, skal du gå ud fra, at den findes overalt, hvor vedkommende har lagt den.

Læs også

• Sådan deler du API-nøgler sikkert
• Links, der udløber: hvorfor korte tidsrum betyder noget
• LinkPilots sikkerhedsarkitektur

Kilder

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