En passordpolicy skal beskytte kontoer gjennom hele livsløpet: opprettelse, daglig innlogging, endring av rolle, gjenoppretting og avslutning. Hvis dokumentet bare beskriver lengde og tegnkrav, står flere av de viktigste angrepsveiene fortsatt åpne. En angriper kan utnytte svak kontogjenoppretting, stjele en aktiv økt eller få tilgang gjennom en gammel tjenestekonto uten å gjette et passord.
Denne arbeidsplanen hjelper virksomheten med å velge regler som kan gjennomføres i egne systemer. Den fastsetter ingen universell norsk passordlengde eller frist for passordbytte. Sikkerheten må vurderes mot risikoen etter artikkel 32 i GDPR. NSMs grunnprinsipper for IKT-sikkerhet er et relevant utgangspunkt for virksomhetens arbeid, og tiltak må tilpasses systemer og trusselbilde.
Finn kontoene før dere bestemmer reglene
Lag en oversikt over personlige brukerkontoer, administratorer, eksterne brukere og maskinidentiteter. Ta med kontoer som fagavdelinger oppretter direkte hos skyleverandører. En felles innloggingstjeneste gir ikke automatisk kontroll over applikasjoner som fortsatt tillater lokale passord. Undersøk hvordan tilgang faktisk skjer, og dokumenter alternative innganger.
Bruk systemkartet til å knytte kontoene til tjenester og eiere. Registrer hvilke kontoer som kan lese store mengder personopplysninger, endre rettigheter eller slå av sikkerhetskontroller. Disse har et annet skadepotensial enn en konto med tilgang til offentlig informasjon. Prioriteringen bør følge faktisk myndighet fremfor stillingstittel.
Skill vanlige brukere fra administratorer
En person som trenger administrative rettigheter, bør ha en tydelig avgrensning mellom vanlig arbeid og administrasjon. Vurder separate kontoer eller andre kontrollmekanismer som reduserer eksponeringen av privilegier. Avklar hvem som godkjenner rettighetene, hvordan de brukes og når de trekkes tilbake. Et sterkt passord oppveier ikke en unødvendig bred rolle.
For nødkontoer må virksomheten beskrive hvor legitimasjonen oppbevares, hvem som kan bruke den og hvordan bruken oppdages. Kontoen må være tilgjengelig når vanlig innlogging feiler, men ikke fungere som en uformell snarvei. Kontroller gjenopprettingsprosessen med et planlagt scenario og dokumenter resultatet. At en nødkonto finnes, viser ikke at noen kan bruke den under driftsstans.
Formuler regler for passord som mennesker kan følge
Beskriv at passord skal være unike for tjenesten og ikke gjenbrukes privat eller mellom uavhengige systemer. Gi ansatte en praktisk måte å håndtere dette på, for eksempel et godkjent passordverktøy med passende tilgangsstyring. Vurder lange passfraser der brukeren selv må huske passordet. Den konkrete utformingen må passe systemets begrensninger og virksomhetens risikovurdering.
Unngå regler som bare oppfylles på papiret. Hyppige pålagte endringer uten en klar begrunnelse kan føre til forutsigbare variasjoner eller lagring på uegnede steder. Et kjent kompromittert passord krever derimot handling. Skill mellom planlagt vedlikehold og hendelsesutløst bytte, og beskriv hvem som vurderer om også aktive økter og gjenopprettingsmidler må tilbakekalles.
Utfylt eksempel på en passordregel
NIST SP 800-63B-4 punkt 3.1.1.2, kontrollert 8. september 2026, krever minst 15 tegn ved passord som eneste faktor. Kortere passord kan tillates som del av flerfaktor, men minst 8 tegn. Referansen anbefaler støtte for minst 64 tegn og beskriver blokkering av kjente svake eller kompromitterte valg, begrensning av mislykkede forsøk og fravær av vilkårlige tegnsammensetningskrav eller periodiske bytter. Dette er et teknisk referansegrunnlag, ikke en norsk lovfestet tallgrense.
Eksempel på virksomhetens eget valg: For personlige kontoer i kundesystemet velger vi minst 15 tegn og flerfaktor. Løsningen skal tillate minst 64 tegn, passordverktøy og innliming. Kjente kompromitterte valg blokkeres, og gjentatte mislykkede forsøk begrenses. Vi pålegger ikke vilkårlige tegnkombinasjoner eller rutinemessig kalenderbytte; mistanke om kompromittering utløser hendelsesvurdering og nødvendig bytte. Administratorer bruker avgrensede kontoer, og gjenoppretting krever kontroll gjennom etablert kanal. Systemeier bekrefter oppsettet før innføring.
Eksemplet gjelder ett definert system. Tjenestekontoer, nødkontoer og lokale aktiveringskoder trenger egne vurderinger; de skal ikke ukritisk få samme regel fordi ordet passord brukes om flere forskjellige mekanismer.
Bruk flerfaktor der risikoen tilsier det
Vurder flerfaktorautentisering for tjenester med høy konsekvens ved misbruk, særlig fjernaksess og administrasjon. Undersøk hvilke metoder tjenesten støtter, hvordan de registreres og hvor motstandsdyktige de er mot aktuelle angrep. En løsning må vurderes som helhet: innlogging, enhetsbytte, mistet telefon og hjelp fra brukerstøtte.
Gi ansatte instruks om uventede godkjenningsforespørsler. De bør vite hvordan de avviser og melder fra, uten å måtte lete i et langt policyvedlegg. Undersøk om systemet tillater eldre innloggingsmetoder som omgår flerfaktorkravet. For Microsoft 365-konfigurasjon må slike valg kontrolleres i den konkrete tjenesten og lisensen; en generell anbefaling dokumenterer ikke at kontrollen er aktiv.
Arbeidsmal for autentiseringskrav
| Kontotype | Vurdering som må fylles ut |
|---|---|
| Vanlig bruker | Innloggingsmetode, tilgangsrolle og hjelp ved tap |
| Administrator | Avgrensning, sterkere kontroll og oppfølging av bruk |
| Ekstern konsulent | Oppdragsgiver, sluttdato og løpende behov |
| Tjenestekonto | Eier, tillatte handlinger og nøkkelhåndtering |
| Nødkonto | Aktivering, oppbevaring og varsling ved bruk |
| Delt arbeidsfunksjon | Individuell sporbarhet og alternativ til delt passord |
Tabellen skal vise gjennomførte valg og åpne mangler. Skriv også hvordan dere kontrollerer resultatet. En rad med «flerfaktor påkrevd» er ufullstendig hvis ingen har undersøkt om et unntak eller en eldre klient tillater innlogging uten den andre faktoren.
Gjør gjenoppretting til en kontrollert prosess
Brukerstøtte må kunne hjelpe en legitim bruker uten å gi en angriper en enklere vei inn. Avklar hvilke signaler som kan brukes til identitetskontroll og hvordan usikkerhet håndteres. Unngå å gjøre offentlig tilgjengelige opplysninger til eneste kontroll. Fødselsdato, stilling eller navnet på en leder kan være kjent for andre.
Ved endring av telefon eller autentiseringsmiddel bør den gamle forbindelsen håndteres uttrykkelig. Vurder informasjon til brukeren gjennom en etablert kanal og kontroll av uvanlige endringer. Oppbevar bare nødvendig dokumentasjon fra verifiseringen. En kopi av identitetsdokumentet kan skape en ny risiko og er ikke automatisk nødvendig for å tilbakestille en intern konto.
Håndter tjenestekontoer og hemmeligheter separat
Programmer og integrasjoner kan bruke nøkler, tokens eller sertifikater i stedet for passord. Gi hver identitet en eier og et avgrenset formål. Begrens rettighetene til handlingene integrasjonen faktisk trenger. Hemmeligheter bør ikke ligge i åpne regneark, e-posttråder eller kildekode som mange kan lese.
Planlegg endring og tilbakekalling uten å stanse driften unødvendig. Kontroller hvilke systemer som bruker nøkkelen før den erstattes, og se etter gamle kopier etterpå. Knytt dette til kryptering og nøkkelhåndtering. Selv om krypteringsnøkler og innloggingstokens har forskjellige funksjoner, trenger begge kontroll med eierskap, bruk og tap.
Hypotetisk eksempel: telefonen blir borte på reise
En tenkt ansatt mister telefonen som brukes til flerfaktor. Brukerstøtte mottar en forespørsel fra en ny adresse om å registrere en erstatning. Rutinen krever at identiteten bekreftes gjennom en allerede etablert kanal eller en annen godkjent metode. Supportmedarbeideren gjør ikke et unntak bare fordi forespørselen haster eller viser til en leder.
Etter kontroll fjernes det tapte autentiseringsmiddelet, relevante økter vurderes og en ny registrering gjennomføres. Ved mistanke om uautorisert tilgang undersøkes sikkerhetsloggene. Eksemplet viser hvorfor gjenoppretting må inngå i policyen: sterke innloggingskrav hjelper lite hvis en angriper kan få dem tilbakestilt gjennom en enkel e-post.
Avslutt kontoer når behovet opphører
Knytt HR-prosessen til teknisk tilgangsavvikling, men ta også med konsulenter, midlertidige roller og integrasjoner. Avklar tidspunkt og ansvar for stenging. Kontroller at tilgangen opphører i relevante tjenester, ikke bare i ett sentralt register. Delte nøkler eller lokale kontoer kan ellers gi fortsatt adgang.
Ikke bruk stenging av en konto som begrunnelse for ubegrenset innsyn i tidligere ansattes innhold. Norsk arbeidsgiverinnsyn i e-post har egne vilkår og prosedyrer. Bevaring, overføring av arbeidsoppgaver og innsyn er forskjellige beslutninger som bør dokumenteres hver for seg.
Kontroller etterlevelsen og behandle unntak
Undersøk et relevant utvalg kontoer: én administrator, én ekstern bruker, én tjenestekonto og én nylig avsluttet konto. Sammenlign faktisk oppsett med policyen. Registrer funn, ansvarlig og tiltak. Utvalget må ikke presenteres som bevis for alle systemer, men kan avdekke svakheter som krever en bredere gjennomgang.
For systemer som ikke støtter ønsket løsning, dokumenteres risiko, kompenserende tiltak og plan for oppgradering eller utfasing. Knytt beslutningen til informasjonssikkerhetspolicyen. Unntak skal være synlige og vurderbare; en teknisk begrensning blir ikke et lovlig sikkerhetsnivå bare fordi den er beskrevet i et register.
Beskriv hva ansatte gjør ved mistanke om misbruk
Rutinen bør forklare hvordan ansatte varsler når de har skrevet inn passord på en mistenkelig side, godkjent en uventet forespørsel eller oppdaget innlogging de ikke kjenner igjen. Be om tidspunkt og relevant sammenheng, men aldri om å sende selve passordet. Gjør kontaktveien tilgjengelig også når den vanlige kontoen er stengt. En telefonkanal eller et kjent alternativ kan være nødvendig for at varslingen skal fungere.
Den som mottar meldingen, må vite hvilke tiltak vedkommende kan gjennomføre selv, og når hendelsesansvarlig skal involveres. Passordbytte alene stanser ikke nødvendigvis aktive økter eller applikasjoner som allerede har fått tilgang. Vurder derfor registrerte autentiseringsmidler, økter, gjenopprettingsadresser og integrasjoner i sammenheng. Dokumenter tiltakene slik at undersøkelsen senere kan skille brukerens legitime handlinger fra mulig misbruk.
Gi til slutt brukeren en kort beskjed om hva som er gjort, og hva som forventes videre. Unngå skyldplasserende språk som gjør andre tilbakeholdne med å melde fra. Erfaringene bør brukes til å forbedre innlogging og opplæring, mens detaljene i den konkrete saken bare deles med personer som trenger dem.