Just-in-time-tilgang og regler for betinget tilgang

Vedvarende privilegier betyr at en bruker alltid har utvidet tilgang, døgnet rundt, uavhengig av om brukeren trenger den eller ikke. Dette er den tradisjonelle modellen for administratorkontoer – administratoren kan når som helst få tilgang til produksjonssystemer, selv klokken tre om natten på en søndag når det ikke foregår legitimt arbeid. Vedvarende privilegier øker risikoflaten dramatisk: kompromitterte administratoropplysninger gir angripere utvidet tilgang umiddelbart, uten at det kreves ytterligere trinn.

Just-in-time-tilgang (JIT) erstatter vedvarende privilegier med midlertidig tilgangsøkning ved behov. Når en administrator trenger privilegert tilgang, ber vedkommende om den med en forretningsmessig begrunnelse. Forespørselen godkjennes (automatisk eller av en leder), privilegiet tildeles for et definert tidsrom (for eksempel én time), og utløper deretter automatisk. All aktivitet overvåkes i dette tidsrommet. Etter utløpet har administratoren ingen privilegert tilgang før en ny forespørsel sendes.

Azure Privileged Identity Management (PIM) er Microsofts skyimplementering av JIT-tilgang. Brukere gjøres eligible for privilegerte roller (for eksempel Global Administrator), men har ikke rollen kontinuerlig. Ved behov aktiverer de rollen fra Azure-portalen, oppgir en begrunnelse, kan måtte bruke MFA og innhente godkjenning, og får rollen i en konfigurert periode (maksimalt 8 timer for de fleste roller). PIM genererer revisjonslogger for hver aktivering til bruk i samsvarsrapportering.

Conditional Access er en if-then-motor for retningslinjer som evaluerer kontekstsignaler før tilgang gis. I stedet for en binær tillatelse eller avvisning basert bare på påloggingsopplysninger tar betinget tilgang hensyn til: Hvem som logger på (brukeridentitet og gruppemedlemskap), Hva vedkommende får tilgang til (applikasjon eller data), Hvor vedkommende befinner seg (IP-adresse, plassering), Når (tidspunkt på dagen), Hvordan (enhetens samsvarsstatus, nettleser kontra innebygd app) og Risiko (risikoscore for pålogging fra identitetsleverandøren).

Retningslinjer for betinget tilgang evaluerer flere signaler samtidig. Viktige signaler omfatter: Enhetssamsvar (administreres enheten av MDM og oppfyller den grunnleggende sikkerhetskrav?), Plassering (er IP-adressen fra en klarert, navngitt plassering eller et fremmed land?), Påloggingsrisiko (har identitetsleverandørens KI flagget denne påloggingen som uvanlig – uvanlig plassering, lekkede opplysninger, umulig reise?), og Brukerrisiko (viser denne kontoen tegn på kompromittering ifølge etterretning fra det mørke nettet?).

Når en retningslinje for betinget tilgang utløses, avgjør tildelingskontrollen hva brukeren må gjøre. Alternativene omfatter: Blokker tilgang fullstendig, Krev MFA, Krev kompatibel enhet, Krev godkjent klientapp (bare administrerte apper er tillatt), Krev passordendring (hvis påloggingsopplysningene er utsatt), eller kombinasjoner av disse kontrollene. Tildelingskontroller gjør det mulig for organisasjoner å skjerpe sikkerhetskravene basert på risikonivået ved tilgangen det bes om.

I tillegg til tildelingskontroller kan betinget tilgang bruke øktkontroller som begrenser hva brukere kan gjøre etter autentisering. Eksempler er å håndheve påloggingsfrekvens (kreve ny autentisering hver time), begrense nedlasting av sensitive filer fra uadministrerte enheter, bruke Microsoft Defender for Cloud Apps-retningslinjer for overvåking av økter i sanntid og begrense kopierings- og innlimingsoperasjoner i sensitive applikasjoner som åpnes fra ikke-klarerte plasseringer.

Navngitte plasseringer i betinget tilgang definerer klarerte IP-intervaller eller geografiske områder. Tilgang fra en navngitt, klarert plassering (for eksempel IP-intervaller for et firmakontor) kan gis med mindre friksjon (uten krav om MFA). Tilgang utenfor navngitte plasseringer – særlig fra høyrisikoland – utløser ytterligere krav til autentisering. Ved å kombinere navngitte plasseringer med deteksjon av umulig reise (en bruker ser ut til å befinne seg på to fjerntliggende steder i løpet av få minutter) kan scenarier med kompromitterte påloggingsopplysninger blokkeres.

Risikobasert betinget tilgang bruker maskinlæringssignaler fra identitetsleverandøren til å evaluere påloggingsrisiko i sanntid. Microsoft Entra ID (tidligere Azure AD) tildeler en risikoscore for pålogging (Low/Medium/High) basert på faktorer som lekkede påloggingsopplysninger i databaser på det mørke nettet, uvanlige påloggingsmønstre og IP-adresser knyttet til skadevare. En pålogging med høy risiko kan automatisk kreve tilbakestilling av passord og MFA, slik at kontoer beskyttes før et IT-team rekker å gjennomgå varselet.

Retningslinjer for betinget tilgang og JIT-tilgang skaper en risiko: Hvis selve identitetsleverandøren blir utilgjengelig, kan administratorer bli utestengt fra systemene de trenger for å gjenopprette den. Nødtilgangskontoer (kontoer for nødtilgang) er kontoer med svært høye privilegier som er unntatt fra retningslinjer for betinget tilgang, oppbevares med påloggingsopplysningene i et fysisk pengeskap og bare brukes i reelle nødsituasjoner. Bruken bør umiddelbart utløse varsler og en gjennomgang etter hendelsen, fordi all bruk utenfor en erklært nødsituasjon er et faresignal.

JIT-tilgang og retningslinjer for betinget tilgang fungerer sammen som komplementære kontroller. Conditional Access avgjør om en bruker kan autentisere seg, og hvilke kontroller vedkommende må bestå. JIT-tilgang avgjør hvilken privilegert rolle brukeren får etter autentisering, og hvor lenge den varer. Sammen gjennomfører de zero trust-prinsippet aldri stol på, verifiser alltid: hver tilgangsforespørsel evalueres i sin kontekst, privilegier er midlertidige, og alle handlinger logges.

I denne leksjonen lærte De at: just-in-time-tilgang erstatter vedvarende privilegier med midlertidig tilgangsøkning ved behov som utløper automatisk, retningslinjer for betinget tilgang evaluerer kontekstsignaler (enhet, plassering, risiko) før tilgang gis, og nødtilgangskontoer gir tilgang i nødsituasjoner utenom vanlige retningslinjer, men må kontrolleres og overvåkes nøye. Neste tema er modellen for delt ansvar på tvers av IaaS, PaaS og SaaS.