Slik deler teamet vårt leverandørlegitimasjon

Del 2 av «Slik bruker Agdir SecretDrop» — en serie om hvor et agtech-selskap og kundene deres faktisk deler hemmeligheter.

Agdir er ikke én integrasjon — det er dusinvis. Rapportering til myndighetene, en regnskapssynkronisering, leverandører av jordsensorer, betalinger, værtjenester. Hver eneste av dem kommer med sin egen legitimasjon: en API-nøkkel, en klienthemmelighet, iblant en privat nøkkel eller et sertifikat.

(Du legger kanskje merke til at vi ikke navngir hvilke leverandører som hører til hvilken legitimasjon. Å publisere et offentlig kart over nøyaktig hvilke levende nøkler vi har for hvilke navngitte produksjonssystemer ville vært sitt eget lille pene selvmål i sikkerhetshygiene — litt drøyt i et innlegg om å håndtere hemmeligheter forsiktig. Man må praktisere det man forkynner. 😉)

De ligger der de skal — i en hemmelighetsbehandler, i miljøvariabler, låst ned. Lagringsproblemet er løst.

Overleveringsproblemet er ikke det.

Hvor legitimasjon faktisk lekker

Legitimasjon lekker vanligvis ikke fra hvelvet. Den lekker i de hverdagslige øyeblikkene mellom mennesker:

• En ny ingeniør begynner og trenger sandkassenøkkelen til en leverandør for å komme i gang.
• Noen ruller passordet til en jordsensorleverandør og må få det nye frem til kollegaen som distribuerer koblingen.
• En nøkkel blir satt opp på noens laptop og må nå frem til en kollega som konfigurerer et nytt miljø.

I hvert eneste av disse øyeblikkene er fristelsen den samme: slenge den i en Slack-DM. «Her er nøkkelen, slett dette etterpå.» Lime den inn i en sak «bare for nå».

Men en Slack-melding blir ikke slettet etterpå. Den beholdes, er søkbar og synkroniseres til hver eneste enhet den kontoen berører. «Bare for nå» er hvordan en levende leverandørlegitimasjon ender opp med å ligge permanent i en chathistorikk som overlever personen som sendte den.

Hva ingeniørene våre gjør

For selve overleveringen går legitimasjonen gjennom SecretDrop som en les-og-brenn-lenke:

1. Lim leverandørnøkkelen, hemmeligheten eller tilkoblingsstrengen inn i SecretDrop.
2. Send engangslenken over Slack eller e-post — lenken er ikke hemmeligheten.
3. Kollegaen åpner den én gang, flytter verdien rett inn i hemmelighetsbehandleren eller miljøet sitt, og lenken selvdestruerer.

Legitimasjonen bor nøyaktig to riktige steder — hvelvet den kom fra og hvelvet den skal til — og aldri i chatten som fraktet den mellom dem.

Hvorfor dette betyr mer for et integrasjonsselskap

Når du integrerer med offentlige systemer og finansiell programvare, er en lekket leverandørlegitimasjon ikke bare ditt problem — den kan eksponere kundedata og bryte tilliten til leverandøren hvis tilgang du har ansvar for. Skadeomfanget av «én nøkkel etterlatt i Slack» er mye større enn det ser ut til.

Regelen vi landet på er enkel:

Hemmelighetsbehandlere er for lagring. Les-og-brenn-lenker er for flytting.

La aldri en levende legitimasjon hvile i en kanal designet for å huske den. Hvis den må reise mellom to personer, reiser den som en lenke som leses én gang og forsvinner.

Det viktigste

• Lagre legitimasjon i en hemmelighetsbehandler — alltid.
• Flytt den med en engangslenke — aldri i en chat, DM eller sak.
• Ruller alt som noen gang har berørt en varig kanal, for sikkerhets skyld.

Hvelvet beskytter hemmeligheten i ro. SecretDrop beskytter den under transport — i det ene risikofylte øyeblikket den er ute i det åpne.

---

Neste i serien: Slik sendte en integrasjonspartner oss en privat nøkkel — trygt.
Tidligere: Slik sendte en bonde et API-token til utvikleren sin.