Hvem har fortsatt tilgang?

Vi har tatt i bruk en åpen kildekode-løsning for innlogging, og drifter den selv. Ikke fordi det manglet ferdige tjenester, men fordi kunder, leverandører og kursdeltakere skifter roller hos oss — og vi ville bestemme selv hvem som slipper inn, uten lisenstekniske utfordringer.

De fleste bedrifter kjenner seg igjen i dette: hvert system har sin egen brukerliste. Én for prosjektverktøyet, én for dokumentasjonen, én for overvåkingen. Hver gang noen begynner, skal det opprettes kontoer flere steder. Hver gang noen slutter, skal de samme kontoene finnes igjen og stenges.

Det første er irriterende. Det andre er et sikkerhetsproblem.

For det er sjelden noen glemmer å *opprette* en konto — da ringer folk og sier ifra at de ikke kommer inn. Det er å fjerne den ingen oppdager. Kontoen blir bare liggende, med tilgangene sine i behold, lenge etter at den skulle vært borte.

Hvorfor vi ikke bare koblet alt til Microsoft

LTS har allerede et Microsoft-miljø, og det nærliggende var å koble hver tjeneste rett dit. På kurssidene våre gikk vi enda lenger: der la vi inn pålogging med Microsoft 365, Live og Gmail, slik at deltakerne kunne bruke kontoen de allerede hadde. Det var godt ment — kursdeltakerne våre kommer fra mange ulike bedrifter, og vi ville ikke tvinge dem til å lage enda et passord.

Det ble vanskelig å vedlikeholde. Tre integrasjoner mot tre ulike organisasjoner, bare for én applikasjon som ikke hadde særlig fokus på innloggingsflyt hos tredjeparter.

Løsningen ble authentik, en åpen kildekode-løsning for identitet og pålogging. Vi har ikke skrevet den selv, men vi drifter den på vår egen infrastruktur. Resten av systemene forholder seg til den. Nå er det én integrasjon per applikasjon — applikasjonen forholder seg til oss, og vi håndterer resten.

Gevinsten er at vi ser hva som skjer når noen logger inn, og kan endre det uten å vente på noen. Skal en ekstern tekniker inn på en ny måte, gjør vi endringen, og teknikeren får et nytt ikon på startsiden sin.

Roller som skifter

Skalering er den tekniske grunnen. Den andre handler om forretning: ikke alle som trenger tilgang hos oss er ansatt hos oss. Kundene våre har sine egne organisasjoner og sine egne påloggingsløsninger. Og på de gratis kursene våre dukker det opp folk vi ikke har noe forhold til ennå — noen av dem blir samarbeidspartnere siden. Vi vet ikke hvem det er på forhånd. Skal alle disse inn i hvert sitt brukerregister for å utføre en jobb, blir situasjonen fort uoversiktlig.

I et typisk prosjekt hos oss er det flere kunder og flere leverandører samtidig. Rollene sitter ikke fast. En leverandør i ett prosjekt er kunde i det neste, og en kunde som anbefaler oss videre blir samarbeidspartner i det tredje.

«Intern» og «ekstern» er derfor ikke to bokser vi kan sortere folk i én gang for alle. Har hver tjeneste sin egen brukerliste, havner den samme personen fem steder med fem ulike roller, og ingen av listene vet om de andre. Da mister vi ikke bare oversikten over tilganger — vi mister oversikten over relasjonen.

Med login.lts.no i sentrum kan vi ta imot de fleste, og justere tilgangsnivået ved behov.

Én samlet oversikt over hvem vi faktisk jobber med er ikke bare et sikkerhetstiltak. Det er en forutsetning for å bygge gode relasjoner, og relasjoner er noe av det viktigste et ingeniørselskap har.

Første tjeneste ut

Vi begynte med Dependency-Track, som vi bruker til å holde oversikt over sårbarheter i programvare. De som har tilgang logger inn med LTS-kontoen sin, og rettighetene følger gruppen de tilhører. En utvikler ser sitt. En administrator ser mer. Ingen får rettigheter fordi noen husket å krysse av i et skjema en gang i fjor — de følger av gruppen, og gruppen er ett sted.

Effekten er den vi var ute etter: tas noen ut av gruppen, er tilgangen borte neste gang de forsøker. Ikke etter en opprydding. Ikke når noen kommer på det.

Fire ting vi tar med oss

Innlogging er kritisk infrastruktur. Når alt henger på én tjeneste, må den tjenesten ha god tilgjengelighet. Det er ikke valgfritt — det er forutsetningen for å kunne samle alt på ett sted.

Tofaktor må være regelen. Når vi gir tillit til eksterne, holder det ikke med passord alene. Vi krever tofaktor for kontoer med økt tilgangsnivå, gjerne via kundens eksisterende Office 365-løsning.

Gi bare den tilgangen jobben krever. Det er fristende å gi litt ekstra, for å slippe spørsmålet igjen om tre uker. Men rettigheter som ble gitt for sikkerhets skyld er nettopp de som blir stående lengst — ingen husker hvorfor de kom, og da er det ingen som tør fjerne dem. Hos oss følger rettighetene gruppen, og gruppene er laget for oppgaver, ikke for personer.

Åpne minst mulig. En innloggingstjeneste som skal nås utenfra, må nås utenfra — men resten av infrastrukturen kan holdes intern for å redusere angrepsflaten.

Målt mot NSMs grunnprinsipper

Nasjonal sikkerhetsmyndighet gir ut *Grunnprinsipper for IKT-sikkerhet*, et sett med tips som gjelder alle norske virksomheter. Vi bruker grunnprinsippene som målestokk framfor å finne på våre egne kriterier. Dette prosjektet gjør at vi kan krysse av et nytt grunnprinsipp:

2.6.3 — «Benytt et sentralisert og automatiserbart verktøy for å styre kontoer, tilganger og rettigheter».

Hva det betyr for deg som kunde

Mest av alt at spørsmålet *«hvem har egentlig tilgang til dette?»* nå har et svar som kan slås opp, i stedet for å måtte etterforskes. Det betyr noe for prosjekter som inneholder tegninger, kildekode og produksjonsdata.

Sikkerhetstiltak gjør ofte hverdagen vanskeligere. Her ble det motsatt.

Etter innlogging møter du en oversikt over programmene du har tilgang til. Ikke bokmerker du har samlet opp gjennom årene, og ikke en lenke noen sendte på e-post i fjor — en liste som er riktig fordi den kommer fra gruppen du tilhører.

Det høres smått ut. I praksis fjerner det en hel kategori spørsmål: hva var adressen til det systemet? Har jeg tilgang, eller er det passordet mitt som ikke virker? Hvem må jeg spørre for å komme inn? Det er spørsmål som koster noen minutter hver gang, og som stilles ofte nok til at minuttene blir til dager.

For en ny medarbeider eller en ny samarbeidspartner er forskjellen større. De logger inn første gang og ser med det samme hva de kan bruke. Ingen venting på kontoer som skal opprettes i fem systemer, ingen opplæring i hvilke lenker som gjelder.

Og endrer rollen seg, endrer listen seg med den. Det er hele poenget.

author avatar
Håvard Bondahl Line

Tagger: