Målet med prinsippet: Virksomheten har oversikt over identiteter og kontoer i informasjonssystemene og styrer tilgang til ressurser effektivt og i henhold til virksomhetens retningslinjer.

Hvorfor er dette viktig?

Angripere forsøker ofte å få kontroll over en legitim bruker i et informasjonssystem. Det neste målet er som regel å øke tilgangen og rettighetsnivået slik at brukerkontoen utnyttes for å ta seg lenger inn i systemet og få tilgang til flere ressurser.

Ansatte som har flere rettigheter enn de trenger er et problem i mange virksomheter. Det er blant annet vanlig at alle ansatte kan skrive til og slette alt av filer og filmapper og også kunne kjøre alt som finnes av programvare. Dette er som regel unødvendig men til stor hjelp for angripere.

Hvis alle brukere har rettigheter til «alt» vil kompromittering av én bruker kunne kompromittere hele IKT-systemet. Rettighetene til de ulike delene av et informasjonssystem bør derfor deles opp for å redusere skaden fra et eksternt angrep eller fra en utro eller en uvøren ansatt. En virksomhet må ha kontroll på brukerne, det vil si kontoene og tilgangene de disponerer samt rettigheter de har mottatt.

Manglende kontroll på ubrukte kontoer er et vedvarende problem. Det finnes mange eksempler på at kontoer til leverandører og tidligere ansatte har blitt misbrukt av en angriper eller utro tjener.

Anbefalte tiltak: Ha kontroll på identiteter og tilganger

Kontroll på identiteter og tilganger er viktig uansett hvor virtualisert («sky-basert») infrastruktur man velger.

Denne tabellen bør sees i sammenheng med tabellen i prinsipp 1.3 - Kartlegg brukere og behov for tilgang.

Anbefalte tiltak: Ha kontroll på identiteter og tilganger
IDBeskrivelse
2.6.1 Etabler retningslinjer for tilgangskontroll. a) Retningslinjene bør dekke flest mulig av ressursene i virksomheten: brukere, klienter, felles-mapper, server-applikasjoner, servere, nettverksenheter, sikkerhetsenheter og databaser. b) Retningslinjene bør følge minste privilegiums prinsipp; ikke gi sluttbrukere, service-kontoer, utviklere eller driftsbrukere flere privilegier enn nødvendig. Alle trenger ikke tilgang til alt. Og hvis man trenger tilgang så holder det ofte med lese-rettigheter, alle trenger ikke rett til å skrive, slette og kjøre. c) Alle kontoer bør kunne spores til en ansvarlig bruker (også upersonlige kontoer uten personnavn). d) Alle kontoer, tilganger og rettigheter bør spores til en ansvarlig rolle og person som godkjente dette. e) Kontoer, tilganger og rettigheter bør revideres jevnlig. Dette er spesielt kritisk mht. kontoer, tilganger og rettigheter for drift og spesialbrukere. f) Gjenbruk identiteter mest mulig på tvers av systemer, delsystemer og applikasjoner (ideelt «Single sign on»). g) Ansvarliggjør brukere mht. at passord er personlige og hemmelige og aldri skal deles med noen, selv ikke med nære kollegaer eller overordnede. Klienter bør i tillegg låses når de forlates av bruker.
2.6.2Etabler en formell prosess for administrasjon av kontoer, tilganger og rettigheter. a) Prosessen bør omhandle i) kontoer til brukere, enheter og systemprosesser, ii) tilganger til systemer og applikasjoner, iii) samt rettigheter mht. operativsystemer (f.eks. admin-rettigheter) og virksomhetens felles brukerdatabase. b) Prosessen bør omfatte hele livssyklusen og omfatte opprettelse, vedlikehold og deaktivering. Deaktiver fremfor å slette kontoer og tilganger slik at revisjonsspor bevares, i henhold til gjeldende lover og regelverk. c) Retningslinjer for tilgangskontroll (2.6.1) og prosess for administrasjon av kontoer, tilganger og rettigheter (2.6.2.a) bør dokumenteres og være kjent i virksomheten.
2.6.3Benytt et sentralisert og automatiserbart verktøy for å styre kontoer, tilganger og rettigheter. a) Styr kontoer, tilganger og rettigheter til flest mulig av ressurser (ref. 2.6.2.a) i virksomheten med helst ett verktøy for hele virksomheten. b) Bruk verktøyet til å holde oversikt over alle kontoer, tilganger og rettigheter. Verktøyet bør kunne utføre mest mulig av retningslinjene i 2.6.1, c) Ved opprettelse av enkelte kontoer (f.eks. innleide) bør man sette foreløpige utløpsdatoer for deaktivering. d) Detekter og følg opp kontoer som ikke har blitt brukt på lenge dersom de ikke er nødvendige (overvåk unntak som f.eks. en leverandørs vedlikeholdskonto). e) Bruk et sentralt verktøy til å kontrollere passord-kvaliteten opp mot virksomhetens sikkerhetskrav, som et minimum bør man hindre bruk av vanlige ord og navn på norsk og engelsk, samt årstall og årstider. Se også [1].
2.6.4 Minimer rettigheter til sluttbrukere og spesialbrukere. a) Ikke tildel administrator-rettigheter til sluttbrukere. b) Håndter spesialbrukere (f.eks. utviklere) som unntaksvis kan ha et faktisk behov for utvidede systemrettigheter, inkl. administrative rettigheter. Oppgavene bør skilles i to kontoer. En for vanlig kontorbruk som e-post og internett-søk og en annen for oppgaver som krever forhøyet («elevated») rettigheter. Disse kontoene bør ha tilstrekkelig sikkerhetsskille og som absolutt minimum ikke ha samme passord.
2.6.5 Minimer rettigheter på drifts-kontoer. a) Etabler ulike kontoer til de ulike drifts-operasjonene (selv om det kanskje er samme person som reelt sett utfører oppgavene), slik at kompromittering av en konto ikke gir fulle rettigheter til hele systemet. Dvs. forskjellige drifts-kontoer for backup, brukeradministrasjon, klientdrift, serverdrift, mm. b) Begrens bruken av kontoer med domeneadmin rettigheter til kun et minimum av virksomhetens drifts-operasjoner. Spesielt bør kontoer med domene-admin rettigheter aldri benyttes interaktivt på klienter og servere (reduserer konsekvensene av «pass the hash» angrep). c) Unngå bruk av upersonlige kontoer («backup_arne» er bedre enn bare «backup») slik at man har god sporbarhet og lettere kan deaktivere kontoer når noen slutter. Hvis det er vanskelig å unngå å ha en upersonlig konto bør man først logge seg inn med en personlig bruker for å ivareta sporbarhet.
2.6.6 Styr tilganger til enheter. a) Identifiser enheter sikkert og unikt med f.eks. sertifikater. Dette er ikke minst viktig for de ansattes klienter. b) Ha klare regler om hvilke nettverks-soner, ressurser og tjenester som enheter skal ha tilgang til.
2.6.7 Bruk multi-faktor autentisering, som smartkort, sertifikater eller engangspassord, for å autentisere brukere. a) Implementer som et minimum multi-faktor på brukerkontoer som har tilgang til kritiske data eller systemer, samt brukere med driftsoppgaver. Der multi-faktor autentisering ikke støttes, bør brukerkontoer bli pålagt å bruke sterke passord på systemet. b) Benytt biometri (f.eks. fingeravtrykk) på klienter som benyttes mye i det offentlige rom (passord-inntasting kan bli observert/filmet). Merk at det kan være personvernsutfordringer mht. biometri, se [3].
Utdypende informasjon

Lenker

NSMs passordråd

Datatilsynet, biometri

UK GOV: Password guidance_-_simplifying your approach

CIS CSC 6 - Access control management