Her i Ur Solutions har vi lenge oppfordret og tilrettelagt for bruk av passordhåndterere til sikker lagring og deling av passord, koder, API-tokens og andre hemmeligheter.
Frem til nyttår var vår foretrukne tjeneste LastPass, men sett i lys av nye opplysninger rundt omfanget av datainnbruddet de opplevde i høst, ble det besluttet å bytte til 1Password. Vår CTO Ola har skrevet en kommentar om hvorfor dette byttet var nødvendig.
Bør vi bare droppe passord-apper? - Det er mye å kritisere LastPass for
I sammenheng med lanseringen av versjon 8 av programvaren sin i 2022, har 1Password rullet ut en rekke funksjoner direkte rettet mot utviklere. Jeg har plukket ut tre jeg liker spesielt godt.
#1: SSH-agenten
Når jeg nevner ordet “SSH-nøkler”, tenker nok de fleste på den obskure filen man en gang i tiden opprettet for å slippe å taste inn passordet sitt hver gang man skal pushe noe til GitHub.
Nå skal det være sagt: Det ikke noe fundamentalt galt med SSH-nøkler slik det fungerer i dag, gitt at man bruker et sikkert nok kryptosystem. Den potensielle fallgruven er at man gjerne gjenbruker den samme nøkkelen på tvers av ulike tjenester – i samme ånd som å gjenbruke passord når man ikke har en passord-manager. Dersom du har flere maskiner er du også nødt til å lage egne nøkler for hver av dem, samt vedlikeholde dem.
Den gode nyheten er at 1Password har støtte for både generering og lagring av SSH-nøkler, samt en egen SSH-agent for å mate inn riktig nøkkel til ulike tjenester på maskinen som bruker SSH – for eksempel git.
Det betyr at man kan gå fra én nøkkel per maskin, til én nøkkel per tjeneste. Disse nøklene kan videre synkroniseres på tvers av alle enheter du har 1Password installert på. I tilfelle en av nøklene blir kompromittert, er det kjapt gjort å erstatte den på denne ene tjenesten, uten å måtte gjøre det til en heldagsoperasjon for å bytte alt.
Selve funksjonen er enkel å ta i bruk: Bare åpne innstillingene og slå på “Use the SSH agent”. Har du biometrisk opplåsing aktivert, vil du få en forespørsel hver gang en nøkkel blir forsøkt tatt i bruk. Ønsker du heller en miks av lokale nøkler og nøkler lagret i 1Password, er det fullt mulig å få til ved å legge til ett eller flere unntak i din lokale SSH-konfigurasjon.
#2: Signere git commits
SSH-nøkler kan brukes til mer enn bare å autentisere nettverkstilkoblinger, for eksempel å signere git commits.
I utgangspunktet bekrefter ikke git forfatterens identitet, noe som kan (humoristisk) utnyttes i git-blame-someone-else. Dette er derimot en reell sårbarhet som kan brukes til å lure inn ondsinnet kode: Rekk opp hånda de som husker å spørre kollegene sine om det var de som faktisk skrev koden du går gjennom.
Heldigvis kan man, på samme måte som med SSH-agenten, konfigurere git til å signere commits ved hjelp av nøkler fra 1Password. Legger man denne nøkkelen i brukerinnstillingene på for eksempel GitHub, vil man få et fint, grønt “Verified”-skilt på alle commits man pusher opp. Sjekk ut denne videoen for hvor enkelt det kan konfigureres!
#3: Provisjonering av .env-filer
For en gjennomsnittlig utvikler må det å sjekke inn .env-filen i git oppleves som å bryte en av de syv dødsyndene. Man hører jevnlig skrekkeksempler der hemmeligheter lakk ut fordi noen hadde glemt å legge til filen i .gitignore, og lastet den opp ved en feiltakelse. Nei, den riktige måten er selvfølgelig å lage en egen fil, uten de hemmelige verdiene, som trygt kan sjekkes inn. Når nye utviklere skal sette opp prosjektet er det bare å be dem hente ut verdiene fra passordhåndtereren – eventuelt dele sin egen .env fil.
Ettersom man allerede har alle hemmelighetene i 1Password, hadde det ikke vært bedre å få applikasjonen sin til å hente dem direkte derfra? Det er faktisk mulig ved hjelp av 1Password sitt kommandolinjeverktøy.
I kulissene blir hvert felt man legger inn i passordhåndtereren tildelt en egen, banelignende ID. Denne kan vi senere bruke til å provisjonere den ekte, hemmelige verdien før applikasjonen skal kjøres – også i produksjon. Dermed kan man trygt både sjekke inn .env-filen i git samt pushe den opp, ennå hvor syndig det føles ut!
La oss si vi har en applikasjon som skal benytte AWS-kontoen vår. Da ville en typisk .env fil sett slik ut:
AWS_ACCESS_KEY_ID="op://aws/Access Keys/access_key_id" AWS_SECRET_ACCESS_KEY="op://aws/Access Keys/secret_access_key"
For å kjøre applikasjonen lokalt, bruker man kommandolinjeverktøyet til å provisjonere alle miljøvariabler før applikasjonen startes på vanlig måte:
$ op run --env-file=".env" -- npm start
Når applikasjonen skal deployes til produksjon er det nødvendig med noe ytterligere oppsett for å sørge for sikker provisjonering av eksterne tjenester. Oppskrift på hvordan du får til dette finner du på 1Password sine nettsider.
- Hei, web- og app-utviklere: Ikke lekk nøkler mens du leker med eksterne integrasjoner!
Flere muligheter
Disse tre funksjonene er de jeg umiddelbart så nytteverdien av, og har tatt i bruk i mitt daglige arbeide.
Det finnes derimot mer funksjonalitet enn dette, og særlig kommandolinjeverktøyet, kombinert med ulike SDKer, gjør at man kan utvikle applikasjoner som bruker 1Password som en sikker skylagringsplattform.
Da har man plutselig et fullgodt alternativ til en “keyvault”-tjeneste fra de store skyløsningene.
