Øvelse gjør mester, heter det. For noen år tilbake oppstod det en uventet driftsstans hos Google, en historie som forteller at selv systemer som fungerer prikkfritt i mange år, plutselig kan gå ned. Da gjelder det å vite hvordan man får dem opp igjen.
Google har en intern passordhvelvtjeneste som de ansatte kan bruke til å lagre og dele passord til enkelte tjenester. I alle fall i 2012 inkluderte dette også passordet til en wifi-tjeneste som fantes om bord i bussene som frakter ansatte og andre mellom Googles ulike avdelinger i San Francisco Bay Area.
Internet Archive hacket – 31 millioner kontoer lekket
Utskifting av wifi-passord
I september 2012 ble dette passordet byttet, noe som ble meddelt via e-post til tusenvis av ansatte. Resultatet av dette ble en kraftig økning i trafikken til passordhvelvet, så stor at det knelte. Tjenesten var opprinnelig blitt lagd for å brukes av bare en liten gruppe systemadministratorer.
Riktignok var også et reservesystem i drift, samt en lastbalanserer som sendte trafikken til denne i stedet. Resultatet var det samme. Også dette knelte, noe som førte til at tjenesten ble helt utilgjengelig og at en driftsingeniør ble varslet.
Sikret med smartkort
Systemet hadde fram til da fungert uten stans i fem år, og systemingeniøren hadde ingen erfaring med hvordan eventuelle feil i tjenesten skulle håndteres. Først etter at ingeniøren forsøkte å starte tjenesten på nytt, oppdaget vedkommende at en slik omstart krevde tilgang til en fysisk HSM-smartkort (Hardware Security Module).
Disse kortene var i alle fall på denne tiden lagret i safer ved flere av Googles kontorer globalt, men ikke ved New York-kontoret hvor den aktuelle ingeniøren befant seg. Ingeniøren tok derfor kontakt med en kollega ved et kontor i Australia, som hadde et slikt kort.
Dette har Tinder og sjakk til felles
Utilgjengelig safekode
Det viste seg at kollegaen i Australia ikke greide å få åpnet safen. Årsaken var at koden til safen var lagret i nettopp det passordhvelvet som var blitt utilgjengelig.
Heldigvis var det en kollega i California som husket koden til safen ved sitt eget kontor, fikk åpnet den og tatt ut smartkortet. Men da ingeniøren i California skulle sette kortet inn i kortleseren, nektet fortsatt passordhvelvtjenesten å starte. I stedet ble det vist en kryptisk feilmelding:
The password could not load any of the cards protecting this key.
Fant fram bormaskinen
Ved kontoret i Australia hadde de nå bestemt seg for å bryte opp safen. Ved hjelp av en bormaskin greide de dette på en times tid. Men det viste seg at også dette smartkortet resulterte i samme feilmelding.
Det skal ha tatt ytterligere en time før gruppen med ingeniører innså at det grønne lyset på smartkortleseren ikke indikerte at kortet var blitt satt inn riktig.
Da de til slutt vendte kortet, fikk de endelig startet passordhvelvtjenesten på nytt.
X er blokkert i Brasil
Sikkerhet og pålitelighet kan være vanskelig å kombinere
Denne historien er gjengitt i en fersk bok, Building Secure & Reliable Systems, skrevet av en gruppe Google-ansatte. I boken deler de ansatte sine erfaringer og beste praksis knyttet til skalerbare og driftssikre systemer som også skal være grunnleggende sikre. E-bokutgaven er fritt tilgjengelig, sammen med to andre i samme serie.
Det første kapittelet i boken innledes av historien vi har gjengitt over. I omtalen av historien, trekkes det fram at både sikkerhet og pålitelighet er avgjørende komponenter for et system en virkelig kan ha tillit til. Samtidig er det vanskelig å bygge systemer som både er sikre og pålitelige.
– Det er lett å gå glipp av det finurlige samspillet mellom pålitelighet og sikkerhet som kan forårsake uventede resultater. Passordhvelvets feil ble utløst av et pålitelighetsproblem – mangelfulle strategier for lastbalansering og lastreduksjon, i tillegg til at gjenopprettingen ble vanskeliggjort av flere tiltak designet for å økte sikkerheten til systemet, skriver forfatterne.
Boken er inndelt i tre seksjoner som tar for seg henholdsvis design, implementering og vedlikehold av systemer, basert på «Site Reliability Engineering»-modellen.
Trakk seg fra millionkontrakt: – For høy risiko
