Slik konfigurerer du kjedede tillatelser
Med kjedede tillatelser kan du automatisere tilgangsstyringen ved å koble tillatelser sammen. Når en bruker får tilgang til en bestemt applikasjon, kan dette automatisk utløse en annen, relatert tillatelse, for eksempel tilgang til en sikker sone eller en lisensoppgradering.
Denne tilnærmingen følger "Safety by Design"-prinsippet ved å sikre at tilgangen er behovsbasert. I stedet for å gi tilgang til en sikker sone fordi en ansatt jobber i helsevesenet, gir du for eksempel tilgang fordi vedkommende har fått tilgang til pasientjournalsystemet.
Når brukeren ikke lenger har tilgang til applikasjoner som krever spesialtillatelsen, oppheves den automatisk. Dette sikrer at brukerne bare har akkurat den tilgangen de trenger, så lenge de trenger den.
Vanlige bruksområder
Sikker sonetilgang: Hvis du gir tilgang til en applikasjon som ligger i en sikker nettverkssone, får brukeren automatisk tilgang til denne sonen. Tilgangen oppheves når brukeren ikke lenger har noen applikasjoner i den aktuelle sonen.
Lisensadministrasjon: Hvis en bruker får tilgang til et bestemt program (f.eks. ACOS Websak), kan det automatisk utløse en oppgradering av Microsoft 365-lisensen fra F3 til E3.
Eksempel: Regel for å gi en tillatelse
Følgende eksempel viser hvordan en regel med avledet verdi kan gi en "Helse og omsorg"-rettighet. Regelen er konfigurert med en OR betingelse, noe som betyr at brukeren bare trenger å oppfylle ett av kriteriene for å få tillatelsen.
Denne regelen gir tillatelsen "Helse og omsorg" (ID 5211) hvis en av følgende betingelser er oppfylt:
Betingelse 1: Brukeren har en bestemt kombinasjon av tittel og avdeling.
Tittelen er en av følgende: Advokat, Direktør, konsulent, Konsulent, leder, Leder, Ordfører, Rådmann, Sjef, sjef.
OG
Avdelingsnummer er
1310.
Betingelse 2: Brukeren får tilgang til en bestemt applikasjon.
Brukeren har applikasjonstillatelse med
SYSTEMROLE.NameId=5711(f.eks. CosDoc).
Arbeidsflyt for tildeling av sonetilgang
Følgende logikk brukes når en bruker får tilgang til en ny applikasjon.
Sjekk applikasjonsplassering: eADM sjekker først om applikasjonen befinner seg i den sikre sonen.
Hvis Ja: Brukeren får tilgang til den sikre sonen. eADM sjekker deretter om tilgang til den sikre sonen også skal gi tilgang til den interne sonen.
Hvis ja, får brukeren også tilgang til den interne sonen.
Hvis nei, får ikke brukeren tilgang til den interne sonen.
Hvis Nei: eADM fortsetter med å sjekke om applikasjonen befinner seg i den interne sonen.
Sjekk intern sone: Hvis applikasjonen ikke befinner seg i den sikre sonen, sjekker eADM om den befinner seg i den interne sonen.
Hvis Ja: Brukeren får tilgang til den interne sonen.
Hvis Nei: Brukeren får ikke tilgang til verken den interne eller sikre sonen basert på denne applikasjonen.
Arbeidsflyt for oppheving av sonetilgang
Følgende logikk brukes når en bruker mister tilgangen til en applikasjon.
Sjekk applikasjonsplassering: eADM sjekker først om applikasjonen brukeren har mistet, befinner seg i den sikre sonen.
Hvis Ja: eADM sjekker om brukeren fortsatt har tilgang til andre applikasjoner i den sikre sonen.
Hvis ja, beholder brukeren tilgang til den sikre sonen.
Hvis nei, oppheves brukerens tilgang til den sikre sonen. eADM sjekker deretter om brukeren har noen gjenværende applikasjoner i den interne sonen. Hvis ikke, blir også tilgangen til den interne sonen opphevet.
Hvis Nei: eADM fortsetter med å sjekke om søknaden var i den interne sonen.
Sjekk intern sone: eADM sjekker om applikasjonen som brukeren har mistet, befinner seg i den interne sonen.
Hvis Ja: eADM sjekker om brukeren fortsatt har tilgang til andre applikasjoner i den interne sonen.
Hvis ja, beholder brukeren tilgang til den interne sonen.
Hvis nei, utfører eADM en siste kontroll for å se om brukeren har tilgang til noen applikasjoner i den sikre sonen som skal gi tilgang til den interne sonen. Hvis ikke, blir brukerens tilgang til den interne sonen opphevet.