Tenk deg at nokon får tilgang til e-posten til økonomiansvarleg i verksemda di. Dei kan lese dialogen med leverandørar, sjå kva fakturaer som er venta, og sende meldingar frå ein avsendar kollegaene stoler på. For ei lita verksemd kan konsekvensane bli store, sjølv om de berre er nokre få tilsette.
Når du spør korleis de er verna mot dette, får du kanskje svaret: «Alle har registrert MFA.» Det er eit godt utgangspunkt. Men det fortel berre at dei tilsette har sett opp ein måte å stadfeste identiteten sin på. Det fortel ikkje kva krav som faktisk gjeld når nokon prøver å få tilgang til e-posten.
For deg som leiar er det derfor nyttig å forstå kva tryggleiksoppsettet gjer, og kva de sjølve kan bestemme. Microsoft tilbyr både eit ferdig grunnvern og verktøy for å tilpasse tilgangskrava. Skilnaden handlar om kor mykje kontroll verksemda har over kva som skal vere godt nok.
Kva betyr det eigentleg at «alle har MFA»?
MFA står for fleirfaktorautentisering. Det betyr at brukaren må stadfeste identiteten sin med meir enn éin type bevis, til dømes eit passord og ei godkjenning i ein app på mobilen. Då skal ikkje eit stole passord åleine vere nok til å oppfylle påloggingskravet.
Sjå for deg at økonomiansvarleg har sett opp Microsoft Authenticator. Metoden er då registrert og klar til bruk. Men det må òg finnast ein regel som krev MFA for den aktuelle tilgangen. Til slutt må pålogginga faktisk oppfylle dette kravet. Registrert, krevd og oppfylt er tre ulike ting.
Ei liste som viser at alle har registrert ein metode, er derfor ikkje nok til å dokumentere korleis e-posten er verna. Den som driftar løysinga, må undersøkje både reglane og kva som skjer ved pålogging.
Samtidig er ikkje talet på godkjenningar på mobilen eit mål på kor godt vernet er. Dersom ein tilsett nettopp har stadfesta identiteten sin, kan ei seinare opning av ein app byggje på denne stadfestinga. MFA kan altså vere krevd og oppfylt utan ei ny melding på mobilen. Påloggingsloggane, som er systemet si oversikt over påloggingar, hjelper IT med å sjå kva krav som gjaldt, og korleis dei vart oppfylte.
Security Defaults gir eit ferdig grunnvern
Security Defaults er Microsoft sitt ferdige grunnoppsett for å verne kontoane i verksemda, tilgjengeleg utan ekstra lisenskostnad. Det krev mellom anna at brukarane registrerer MFA, stiller MFA-krav til bestemte administratorroller og blokkerer eldre påloggingsmetodar som ikkje støttar MFA.
For vanlege brukarar avgjer Microsoft når det skal kome eit MFA-krav, ut frå mellom anna stad, eining, rolle og oppgåve. De får dermed eit reelt grunnvern, men kan ikkje tilpasse enkeltreglane i Security Defaults. Oppsettet blir slått på eller av som ei samla løysing.
For ei verksemd som treng å kome i gang, kan dette vere eit nyttig utgangspunkt. Men standardoppsettet gir ikkje rom for å leggje til eigne krav, som at tilgang til e-post òg skal krevje ein PC som oppfyller bestemte tryggleikskrav. Slike behov må løysast på ein annan måte.
Conditional Access let dykk bestemme tilgangskrava
Conditional Access kan omsetjast til vilkårsbasert tilgang. Det er ein funksjon i Microsoft Entra ID, tenesta som handterer identitet og tilgang i Microsoft 365. Funksjonen let dykk setje reglar for kven som får tilgang, kva tenester reglane skal gjelde for, og kva krav som må vere oppfylte.
Gå tilbake til økonomiansvarleg. Verksemda kan bestemme at tilgang til e-post skal krevje både MFA og ei eining som oppfyller definerte tryggleikskrav. Ein privat PC som ikkje oppfyller desse krava, skal då ikkje få tilgang gjennom det aktuelle oppsettet, sjølv om brukaren kan stadfeste identiteten sin.
Det er eit konkret val om korleis verksemda sine data skal vernast. For den tilsette betyr det òg at arbeidskvardagen må vere planlagd: Vedkomande treng utstyr og påloggingsmetodar som faktisk oppfyller krava.
De kan til dømes bruke Conditional Access til å:
- Krevje MFA for dei brukarane og tenestene de vil verne. Då blir omfanget definert i eigne reglar, og de kan undersøkje om nokon fell utanfor.
- Stille strengare krav til administratorar. Desse kontoane kan endre oppsett og tilgangar for mange andre, og kan derfor få krav om pålogging som er motstandsdyktig mot phishing, altså forsøk på å lure brukaren gjennom falske påloggingssider.
- Krevje at eininga oppfyller tryggleikskrava dykkar. Dette føreset at ei teneste for einingsstyring, til dømes Intune, vurderer eininga og gir informasjonen vidare til tilgangskontrollen.
Moglegheitene gir òg eit ansvar. Reglane må vere rett sette opp, testast og følgjast opp. Å ha Conditional Access i lisensen er ikkje i seg sjølv dokumentasjon på at vernet er teke i bruk eller dekkjer behova dykkar.
De kan allereie ha lisensen de treng
Conditional Access krev som hovudregel Microsoft Entra ID P1 for brukarane som er omfatta. P1 er inkludert i Microsoft 365 Business Premium. Har de denne lisensen, kan de derfor allereie ha tilgang til funksjonane som trengst for å stille eigne krav om MFA og eining.
Her er det nyttig å skilje mellom to måtar å snakke om risiko på. De kan sjølve vurdere kva eit innbrot i e-posten vil koste, og bruke P1 til å setje strengare tilgangskrav på bakgrunn av det. De treng ikkje P2 berre fordi avgjerda byggjer på ei risikovurdering.
Vil de derimot at reglane skal reagere på Microsoft sine automatiske vurderingar av brukarrisiko eller påloggingsrisiko, krev desse funksjonane Entra ID P2. Det kan vere aktuelt som eit ekstra lag med vern. Kva de treng, bør avgjerast ut frå behova og korleis løysinga skal driftast.
Kva bør du be IT eller driftsleverandøren om?
Du treng ikkje kunne konfigurere desse reglane sjølv. Som leiar kan du starte med konsekvensane: Kva betyr det om nokon tek over ein konto, kjem inn i kundedokument eller sender e-post i verksemda sitt namn? IT eller driftsleverandøren kan så vise korleis dagens vern møter desse behova.
Be om ein gjennomgang som tek utgangspunkt i faktiske arbeidssituasjonar. Kva skjer når økonomiansvarleg opnar e-post frå ein jobb-PC? Kva skjer frå ein privat PC? Og kva krav gjeld for den som kan endre tryggleiksoppsettet? Slike døme gjer det lettare å forstå kva de har valt, og kvar det finst unntak.
Tre spørsmål er særleg nyttige:
- Kva krav gjeld i dag for dei ulike brukarane og tenestene våre, og kva unntak har vi?
- Kan de vise med testar og påloggingsloggar at krava fungerer slik vi har avtalt?
- Kva risiko står att, kven har godteke den, og kven har ansvar for å følgje opp oppsettet?
Dersom gjennomgangen viser at de bør gå frå Security Defaults til Conditional Access, må overgangen planleggjast. Security Defaults skal erstattast med aktive tilgangsreglar, og Microsoft seier at desse må aktiverast straks grunnoppsettet blir slått av. Ein regel som berre står i rapporteringsmodus, viser korleis den ville ha slått ut, men handhevar ikkje vernet. Avtal derfor både testing, sjølve overgangen og kontrollen etterpå med den som skal utføre arbeidet.
For den som skal gjere den tekniske gjennomgangen, har eg samla verktøy og skrive ei eiga fordjuping om grunnoppsett, unntak og oppfølging:
Heilt ærleg
Eg meiner «alle har registrert MFA» er eit for smalt svar når ein leiar spør om verksemda er godt nok verna. Svaret seier noko om førebuinga, men lite om kva tilgangskrav som gjeld i praksis.
Security Defaults er ein nødvendig grunnmur når lisensane ikkje gir rom for meir tilpassa vern. For verksemder med svært låg risiko kan det vere eit utgangspunkt.
Men heilt ærleg: Eg meiner dette er for tynt som varig tryggleiksnivå for norske små og mellomstore verksemder. Få tilsette betyr ikkje låg risiko.
Conditional Access gir dykk høve til å tilpasse vernet til behova. Be den som driftar Microsoft 365 om å forklare kva som er valt, kvifor det er valt, og vise at det fungerer.