Sikkerhetshygiene: Færrest mulig privilegier

Forfatter:

Carl Bretteville

[email protected]

Carl har levd i sikkerhetsverden i mye av sin profesjonell karriere, og besitter både utvikler-, prosjekt- og ledelseserfaring fra krevende sikkerhetsprosjekter. En stor faglig nysgjerrighet gjør at han alltid er oppdatert, og Carl beskrives av kunder som faglig sterk, pedagogisk og grundig.

Prinsippet om færrest mulig privilegier, eller «least privilege», er en viktig byggestein innen sikkerhet. Du skal ha rettigheter til det du trenger for å gjøre jobben, ikke mer.

I mange sammenhenger er dette selvsagt. For eksempel vil det i en organisasjon med eget serverrom være få med tilgang til selve datarommet. Finanssystemene i en bedrift skal generelt være tilgjengelige kun for de som jobber i økonomi- eller finansavdelingene.  I HR systemene skal hver ansatt ha tilgang til kun sine egne opplysninger, ikke kollegaenes data. Innen militære og etterretning er «need to know» et ufravikelig prinsipp. Denne typen segregering er helt naturlig og eksempel på prinsippet om færrest mulig privilegier.

Når serverrommet virtualiseres eller erstattes helt eller delvis av ressurser i sky, må vi huske på prinsippet om færrest mulig privilegier. Det er enkelt å gi personer tilgang til administrasjonsverktøyene for virtuelle maskiner eller administrasjonskonsollet hos skytjenesteleverandøren. Tilgangen bør likevel begrenses til dem som har et reelt behov. Videre bør tilgang bare gis til de ressursene de har behov for å nå. Nivået for tilgang justeres etter hvilke roller den enkelte har. Med andre ord følge prinsippet om færrest mulig privilegier.

Det stopper ikke med brukere. Prinsippet er like gyldig for prosesser og maskiner. Systemer må designes med dette som en del av grunnmuren. Det vil være fristende å la alle prosesser og maskiner ha fulle rettigheter fra starten i et prosjekt «for å ikke hindre fremdrift», og la ambisjonen være at avgrensninger skal implementeres i sluttfasen av prosjektet. Før et prosjekt bestemmer seg for en slik plan, må det vurdere kostnaden i tid og innsats som kreves for å gjennomføre dette prinsippet i etterkant. Det bør foreta en risikovurdering og se på om dette vil gi en fullgod løsning. Enkelte vil kanskje tro det, men erfaring viser at dette er naivt. Det er bedre å ha dette med som en rammebetingelse i prosjektet og bygge på blant annet dette prinsippet hele veien.

Open source er et gode. Det har revolusjonert måten utvikling foregår på og hvor raskt det går å utvikle systemer. Det kan dog ikke være unntak fra prinsippet for systemer som benytter seg av open source. Snarere tvert imot. I prosjekter som tar inn open source-komponenter, må vi være ekstra påpasselige med å holde systemets privilegier til ett minimum. Koden er ikke skrevet av prosjektet selv, utviklerne kjenner ikke detaljene i den og svært ofte bygger ett open source prosjekt på ett eller flere andre. Dette skaper en rekke av eksterne kodeleveranser («software supply chain») som prosjektet må håndtere og dermed sikre.

Open Web Application Security Project (OWASP) har nylig publisert 2017-utgaven av sin ti på topp liste over sårbarheter i webapplikasjoner. Denne bygger opp under hvor essensielt det er å følge prinsippet om færrest mulig privilegier. Flere av sårbarhetene på listen er gjengangere fra tidligere utgaver. Det ser ikke ut til at vi er i stand til å lage systemer uten dem. Å følge prinsippet om færrest mulig privilegier vil i det minste hjelpe til med å redusere det potensielle skadeomfanget skulle en trusselaktør utnytte en eksponert sårbarhet. Det er viktig å huske at truslene kan komme fra innsiden så vel som utsiden, en trusselaktør vil søke tilgang via konti som har høyest mulig privilegier.

For oss som jobber med sikkerhet, hevdes det at sikkerhet «alltid» vinner over bekvemmelighet. Det er nok et ønske, for i praksis vinner bekvemmelighet eller funksjonalitet over sikkerhet. Mange vet bedre enn å kjøre som administratorer på sin egen arbeidsstasjon eller i Azure- og AWS konsollet, men mange gjør det likevel. Det er for mye mas å kjøre som en vanlig bruker så vi er villige til å ta risikoen det innebærer å kjøre som administrator. Mye smerte hadde vært spart dersom en bruker med reduserte privilegier hadde vært brukt.

Mange norske nettbutikker benytter en utenlandsk betalingsformidler som også tilbyr privatpersoner betaling mot faktura. For å få faktura, må jeg bekrefte at jeg er meg ved å gi selskapet mitt personnummer. En stor aktør innen norsk netthandel benytter en annen betalingsformidler som også tilbyr privatpersoner betaling mot faktura. Denne formidleren har det samme behovet for å bekrefte at jeg er meg. Implementasjonen deres er at jeg «signerer» bestillingen med BankID. I det første tilfellet må jeg gi formidleren rettigheten til å lagre mitt personnummer og stole på at de klarer å beskytte dette. I det andre tilfellet bekrefter at jeg er meg på en måte som bare er gyldig for denne ene transaksjonen. Den andre er en implementasjon som følger prinsippet om færrest mulig privilegier, den første er det ikke.

Innføringen av GDPR vil hjelpe. Prinsippet om færrest mulig privilegier er en av grunnsteinene i GDPR og det kan påstås at alt starter med dette. I GDPR heter det riktig nok «privacy by design», men er å anse for det samme. Underleverandører som behandler sensitive data på vegne av en bedrift, må derfor ha en databehandleravtale som regulerer hvem og hva som har tilgang til sensitive opplysninger. GDPR er først og fremst fokusert på sensitiv personinformasjon. Vi bør allikevel bruke de samme prinsippene for når vi setter sammen systemer uansett hvilke typer data de inneholder.