Sikkerhet
Denne siden sier både hva vi beskytter og hva vi ikke kan beskytte. En sikkerhetsfortelling som mangler den andre halvdelen, får leseren til å forveksle en liste med en garanti.
Utgangspunkt
Å publisere en pakke er å kjøre kode på maskinen til hver eneste ingeniør som installerer den. Hvert sikkerhetsvalg i dette produktet er først veid opp mot ett spørsmål: gjør denne endringen det lettere å publisere uten rettighet?
Pakkene er signert (ECDSA P-256)
Signaturfilen reiser inne i pakken. Den signerer et manifest med avtrykkene av filene, pakkens betegnelse og versjonen — ikke bare et avtrykk av arkivet.
Ble bare avtrykket signert, kunne et gammelt, korrekt signert arkiv skyves inn under et nytt versjonsnummer: signaturen ville bestått sjekken, og brukeren ville installert et verktøy med en kjent sårbarhet som «oppdatering».
Den private nøkkelen ligger IKKE på serveren
Serveren bare sjekker. Signeringen skjer på maskinen til den som publiserer, med et eget verktøy.
Lå nøkkelen på serveren, kunne den som får tak i den, endre en pakke og signere den på nytt — noe som ville gjort signaturen forgjeves.
Klienten sjekker også
Tillegget på ingeniørens maskin sjekker signaturen selv, og listen over betrodde nøkler den bruker, kommer ikke fra serveren.
Signaturen finnes nettopp fordi serveren ikke kan tas på ordet. Å hente tillitslisten fra den samme serveren ville stille opphevet den opprinnelige antakelsen.
En revisjonslogg som ikke slettes
Hver publisering, hver rettighetsendring og hver kanalbeslutning skrives inn for alltid. Det finnes med vilje ingen vei til endring eller sletting, og oppryddingen etter lagringstiden rører den ikke.
«Hvordan havnet dette verktøyet her» spørres som regel måneder senere. Den dagen er en post som kunne vært slettet, en post som aldri har vært.
Firøyeprinsippet, valgfritt
Å rulle en versjon ut til en bredere kanal kan kreve godkjenning fra en annen administrator, og den som ba om det, kan ikke godkjenne sin egen forespørsel. Tilbakerulling krever aldri godkjenning.
Som standard er det slått av. I et team på tre blir hindringen på få uker til en melding som godkjennes uten å bli lest; en kontroll man tror beskytter, men som ikke gjør det, er verre enn ingen kontroll i det hele tatt.
Å pakke ut et arkiv er i seg selv en angrepsflate
Opplastede arkiver sjekkes for utbrudd av mappen (zip-slip) og for utpakkingsbomber, og størrelsen etter utpakking er begrenset.
Å pakke ut et arkiv ser uskyldig ut. Et særskilt forberedt kan skrive filer utenfor målmappen eller fylle serverens disk.
Innlogging uten passord
Brukerne logger inn med en engangskode sendt til adressen sin. Økten går på et kortlevd token; fornyingstokenet er aldri synlig for koden i nettleseren.
Finnes det ingen passordhvelv å stelle med, finnes det heller ingen passorddatabase som kan lekke. Og gjenbruk av et allerede tilbakekalt fornyingstoken behandles som tegn på tyveri: økten lukkes.
Du ser hva du installerer
Installasjonsmappen inneholder en maskinlesbar komponentliste (SBOM CycloneDX) og migreringsskript for begge databasene.
IT-avdelingen deres må kunne sjekke hva som havner på serveren før det havner der. Når en sårbarhet meldes i en avhengighet, blir «har vi den?» til et søk gjennom filer.
Hva vi ikke kan beskytte
Dette er ikke mangler, men grenser. De følger av oppbygningen, og å påstå det motsatte ville vært usant.
- To administratorer som jobber sammen. Firøyeprinsippet stopper én, ikke to.
- Serverens systemadministrator. For den som har tilgang til databasen og filsystemet, er ingen kontroll på applikasjonsnivå en hindring.
- Maskinen der signeringsnøkkelen ligger. Nøkkelen er ikke på serveren, men den er et sted; faller den maskinen, faller signaturen med.
- Bevisst skjult ondsinnet oppførsel. Gjennomgangen vår av pakker er heuristisk, og vi påstår ikke at den fanger kode som prøver å skjule seg.
- Datalekkasje. Et installert verktøy kjører med ingeniørens egne rettigheter og kan lese alt de rekker til. Det begrenses av kontrollene i operativsystemet og nettverket, ikke av dette produktet.
- Sikkerheten i sikkerhetskopiene deres. Kopien av databasen ligger i deres hender, og alt i den er verdt nøyaktig like mye som det levende systemet.
Melde fra om en sårbarhet
Har du funnet en, skriv til oss. Vi tar meldinger på alvor, utelukker ikke den som melder fra, fra prosessen, og sier fra når rettelsen kommer.