Sådan deler du API-nøgler sikkert

Indsæt aldrig en API-nøgle i en chat eller en e-mail. Send den som et hemmeligt engangslink: nøglen krypteres i din browser, dekrypteringsnøglen bliver i den del af linket, der står efter #, og den gemte kopi destrueres, når linket er åbnet én gang. Roter derefter alle nøgler, der allerede er indsat i klartekst.

Resten af guiden går i detaljer: hvorfor de oplagte kanaler svigter, den præcise fremgangsmåde ved overdragelsen, hvad du gør, når en nøgle alligevel lækker, og hvornår et engangslink er det forkerte værktøj.

Hvorfor er det usikkert at sende en API-nøgle i Slack eller via e-mail?

Fordi begge gemmer beskeden, så længe noget som helst beholder den, og undervejs kopierer den til alle enheder og alle eksporter.

• Begge kan gennemsøges for altid. En nøgle, der blev delt i 2023, kan blive kilden til din næste sikkerhedshændelse. Angribere, der kommer ind i en virksomheds chat eller postkasse, søger rutinemæssigt efter netop de tegnfølger, som API-nøgler ligner: sk_live, AKIA, ghp_, Bearer.
• Begge synkroniserer overalt. Telefoner, private bærbare og tablets er enheder, som dine sikkerhedskontroller ikke dækker, og som din politik for fjernsletning ikke kan nå.
• Begge bliver eksporteret. Compliancegennemgange, juridisk bevisindsamling og eksport af arbejdsområder laver alle kopier af historikken. Hver eksport er endnu et sted, nøglen findes.
• Begge overlever, når folk forlader virksomheden. Konsulentens opgave slutter, men DM-tråden med din Stripe-nøgle bliver liggende.

Lægger du en hemmelighed i et af værktøjerne, accepterer du, at den findes overalt, hvor beskeden ender, så længe noget beholder den. Ingen af systemerne er bygget til at glemme.

Før du deler: gør nøglen mindre

Den bedste overdragelse er en, hvor nøglen næsten ikke betyder noget. Før du opretter noget, så giv nøglen så få rettigheder som muligt allerede ved kilden:

• Afgræns den. Stripes begrænsede nøgler, GitHubs finmaskede personlige adgangstokens og AWS IAM-politikker, der er afgrænset til bestemte handlinger og ressourcer: de fleste seriøse udbydere lader dig lave en nøgle, der kun kan den ene ting, modtageren har brug for.
• Vælg skrivebeskyttet, medmindre modtageren reelt skal kunne skrive.
• Sæt udløb hos udbyderen, hvor platformen understøtter det (GitHubs finmaskede PAT'er, midlertidige AWS-loginoplysninger via STS). Så har selv en lækket nøgle en holdbarhed, uanset hvad du gør senere i forløbet.
• Navngiv den efter modtageren (vendor-x-readonly), så du om et halvt år kan se med ét blik, om den skal tilbagekaldes, i stedet for at skulle grave i historikken som en arkæolog.

En afgrænset, skrivebeskyttet nøgle med udløb gør det værst tænkelige læk fra en sikkerhedshændelse til en irritation.

Sådan foregår overdragelsen

1. Opret nøglen i kildesystemet (AWS, Stripe, dit eget API) med de færrest mulige rettigheder, som beskrevet ovenfor.
2. Indsæt den i et hemmeligt engangslink med Slet efter læsning slået til og det korteste udløb, der passer: 1 time er den korteste forudindstilling, derefter kommer 24 timer og 7 dage, og på Pro kan du vælge en dato og et klokkeslæt selv. Linket skal leve lige længe nok til selve overdragelsen og ikke længere.
3. Tilføj en adgangssætning, og send den via en anden kanal: linket via e-mail, adgangssætningen via sms eller en DM i Slack. I LinkPilot er adgangssætning, selvvalgt udløb og revisionsloggen Pro-funktioner til 29 $ om måneden. Lækker den ene kanal, har angriberen stadig kun halvdelen af puslespillet. (LinkPilot hasher adgangssætningen med SHA-256 i browseren, før den sendes. Selve adgangssætningen når aldrig serverens database eller logfiler, og der er en grænse på 5 forsøg pr. IP-adresse pr. minut.)
4. Send linket.
5. Bekræft via en anden kanal, at modtageren har hentet nøglen, og tjek revisionsloggen: én visning, på det forventede tidspunkt og fra det forventede sted. Det er din kvittering.

Bliver linket ikke åbnet, før det udløber, så tilbagekald det, og send et nyt. Forlæng det ikke, og genbrug det ikke.

Eksempel: sådan overdrager du en begrænset Stripe-nøgle

# 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'

Det oplever modtageren: Når linket åbnes, vises en side med en Vis-knap, ikke nøglen. Forhåndsvisningsbots og e-mailscannere, der henter URL'en på forhånd, får kun metadata, fordi en visning kun registreres ved det bevidste klik på Vis og aldrig ved en GET. Når modtageren klikker på Vis (og indtaster adgangssætningen, hvis der er en), ser modtageren nøglen præcis én gang. Derefter overskrives det gemte indhold, og linket returnerer HTTP 410. Selv hvis e-mailen bliver videresendt rundt i hele virksomheden, kan kun den første, der åbnede linket, nogensinde have læst nøglen, og revisionsloggen viser dig, hvem det var.

Hvilken kanal til hvilken overdragelse

Hvad skal du gøre, hvis en API-nøgle lækker?

Betragt den som kompromitteret, og roter den hos udbyderen. At slette beskeden hjælper ikke. Det gælder enhver nøgle, der har været i en chatbesked, en e-mail, et skærmbillede, et git-commit eller et offentligt opslag på en paste-tjeneste. I denne rækkefølge:

1. Udsted den nye nøgle først, hvis udbyderen tillader to aktive nøgler. Så undgår du nedetid for de legitime brugere af nøglen.
2. Tilbagekald den lækkede nøgle hos udbyderen. Det er det eneste trin, der faktisk stopper eksponeringen. At slette beskeden i Slack gør det ikke.
3. Overdrag den nye nøgle på den rigtige måde: engangslink, adgangssætning og kort udløb, som beskrevet ovenfor.
4. Tjek udbyderens brugslog for den lækkede nøgle i perioden mellem læk og tilbagekaldelse. Uventede kald betyder, at det nu er en sikkerhedshændelse og ikke bare en oprydning.
5. Fjern årsagen til, at nøglen blev indsat ved at lægge hemmeligheden i dine miljøvariabelværktøjer, der står i .gitignore, slå hemmelighedsscanning til hos din repo-vært eller rette den driftsvejledning, der fik nogen til at sende den i en DM.

Hele forløbet bør tage minutter. Er det så skræmmende at rotere en nøgle, at folk undgår det, er den skrøbelighed den egentlige sårbarhed. Ret den først.

Det skal du undgå

• At sende den samme hemmelighed igen. Roter i stedet. Sender du den igen, forsvinder den revisionshistorik om ”præcis én eksponering”, som var grunden til at bruge et engangslink.
• Lange udløbsperioder. Vælg kort som standard. De fleste overdragelser er klaret på få minutter, og et vindue på 8 timer er bare et længere læk.
• At springe adgangssætningen over. Den koster næsten ingenting og beskytter mod, at URL'en lækker ved et uheld: videresendte e-mails, skærmdeling eller nogen, der kigger med på en delt skærm.
• Skærmbilleder af nøgler. De havner i kamerarullen, i fotosynkronisering i skyen og i billedsøgning. Et skærmbillede er lige så permanent som en besked i chatten, men sværere for dig at søge i og let for OCR at læse.
• At bruge linkværktøjet som opbevaring. Linket er budet, ikke boksen. Modtageren bør gemme nøglen i en adgangskodeadministrator eller i sine miljøvariabelværktøjer, så snart den er modtaget.

Når et engangslink er det forkerte værktøj

Ærligt talt har metoden sine grænser:

• Loginoplysninger mellem maskiner hører hjemme i en hemmelighedsadministrator eller i platformens eget lager og indsættes ved udrulning eller under kørsel. Et menneske, der klikker på et link, er ikke et udrulningstrin.
• Fælles loginoplysninger, der skal bruges længe, hører hjemme i en adgangskodeadministrator med reel adgangsstyring og tilbagekaldelse for hver enkelt person.
• Hyppig rotation (nøgler, der skifter hver time) bør automatiseres hele vejen. Mennesker og links bør slet ikke indgå i det forløb.
• Hemmeligheder, som ingen tredjepart overhovedet må røre: flyt overdragelsen væk fra nettet. Opdatering, 29. september 2026: Oprindeligt stod der her, at LinkPilot ikke påstod at have E2EE, og at du i stedet skulle bruge et værktøj med end-to-end-kryptering. LinkPilot krypterer nu tekstindhold i browseren og gemmer derfor kun chiffertekst, og det samme gælder vedhæftede filer. Siden om sikkerhedsarkitektur beskriver præcist, hvad der er beskyttet, og hvad der ikke er.

I det almindelige tilfælde, hvor ét menneske giver én hemmelighed til et andet menneske én gang, er engangslinket med adgangssætning og kort udløb den stærkeste enkle metode, der findes.

Læs også

• Hvorfor URL'er lækker følsomme oplysninger
• Sikker deling af adgangskoder: 5 metoder sammenlignet
• LinkPilots sikkerhedsarkitektur
• Sammenligning af API'er til at forkorte URL'er
• Gratis generator til hemmelige links

Kilder

• 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.