Slik bruker Agdir SecretDrop · Del 3

Slik sendte en integrasjonspartner oss en privat nøkkel — trygt

Noen ganger må en partner sende deg en faktisk privat nøkkel for å sette opp en sikker integrasjon. Her er den trygge måten å flytte en mellom to selskaper.

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

Som oftest sender du aldri en privat nøkkel. Hele poenget med et nøkkelpar er at den private halvdelen blir værende: du genererer det, du registrerer den offentlige halvdelen hos den som trenger å verifisere deg, og den private halvdelen forlater aldri maskinen din.

Men en sjelden gang må en privat nøkkel virkelig flyttes mellom to selskaper. Dette er historien om en av de gangene.

Utgangspunktet

En integrasjonspartner — et presisjonslandbruksselskap som bygde en toveis datastrøm med Agdir — kjørte API-et sitt bak gjensidig TLS. Vanlige API-nøkler var ikke nok for dem: for i det hele tatt å åpne en forbindelse må den som ringer opp, presentere et klientsertifikat som partneren har utstedt og stoler på. Det er et solid oppsett, og et vanlig et når to virksomheter utveksler sensitive data maskin-til-maskin.

For å la Agdirs kobling autentisere seg genererte partnerens driftsteam et klientsertifikat og dets private nøkkel spesifikt for oss. Den private nøkkelen er legitimasjonen. Uten den kan ikke integrasjonen koble til; med den kan hvem som helst utgi seg for koblingen vår mot API-et deres.

Så nå hadde to selskaper et problem som enkeltpersoner møter hver dag, bare med høyere innsats: hvordan får du en levende privat nøkkel fra deres side til vår uten at den lekker på veien?

Slik går det vanligvis galt

Standarden i B2B-integrasjoner er nedslående uformell:

Zip sammen sertifikatet og nøkkelen, send det som et e-postvedlegg.
Legg passfrasen i en andre e-post («for sikkerhets skyld»).
Eller slipp begge i en delt sak i hvilket som helst støtteverktøy som kobler de to teamene.

Hver eneste av disse etterlater en permanent kopi av en privat nøkkel i et system ingen av selskapene fullt ut kontrollerer — e-postservere, sikkerhetskopier, en saksbehandlerdatabase, innboksene til hvem enn som blir CC-et senere. En privat nøkkel som havner i en e-posttråd, er en privat nøkkel du aldri virkelig får tilbake.

Og i motsetning til et passord kan du ikke bare «endre det» stille — å tilbakekalle og utstede på nytt et klientsertifikat betyr å koordinere en rullering på tvers av begge selskapene. Mye bedre å ikke lekke det i utgangspunktet.

Hva vi gjorde i stedet

Partneren sendte nøkkelen gjennom SecretDrop:

De limte den private nøkkelen (PEM) inn i en engangslenke, og sendte passfrasen som en separat les-og-brenn-lenke.
De delte begge lenkene med integrasjonsingeniøren vår over den vanlige kanalen — e-post var greit, fordi en lenke ikke er en nøkkel.
Ingeniøren vår åpnet hver lenke én gang, lastet sertifikatet og nøkkelen rett inn i hemmelighetsbehandleren vår, og begge lenkene selvdestruerte.

Den private nøkkelen gjorde én enkelt reise — fra deres hvelv til vårt — og etterlot ingen kopi i noen innboks, sak eller chat på noen av sidene. Hvis noen senere graver gjennom e-posttråden som satte opp integrasjonen, finnes det ingenting sensitivt der å finne.

Det viktigste

Hvis du er en partner som må overlevere et annet selskap en privat nøkkel, et sertifikat eller hvilken som helst levende legitimasjon:

Aldri send den på e-post eller som vedlegg. Vedlegg er den mest permanente, mest videresendbare kopien av alle.
Send den som en les-og-brenn-lenke, og send en eventuell passfrase som en andre, separat lenke.
Bekreft at mottakeren åpnet den, og betrakt så overføringen som ferdig — hemmeligheten finnes ikke lenger noe sted under transport.

Sikre integrasjoner er bare så sikre som øyeblikket du satte dem opp. En privat nøkkel som bare eksisterte i de få sekundene det tok å laste den inn i et hvelv, er en som ingen fremtidig sikkerhetsbrudd — på noen av sidene — noen gang kan eksponere.