It-sikkerhedstekst ST9

Transkript

1 It-sikkerhedstekst ST9 Single Sign-On og log-ud Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST9 Version 1 Juli 2015

2 Single Sign-On og log-ud Betegnelsen Single Sign-On (SSO) har ikke nogen entydig definition eller betydning. Det kan dække over mange forskellige typer af løsninger. Nogle typer af SSO betegnes også som "Silent log in" (lydløst login). Generelt kan man dog sige, at betegnelsen SSO bruges om løsninger, hvor man i login-processen mindsker det antal gange, brugeren skal foretage login i traditionel forstand. For at forklare dette nærmere er det en fordel først at klarlægge forskellen mellem følgende begreber: 1. Handlingen: at foretage login 2. Tilstanden: at være logget på 3. Handlingen: at foretage log-ud 4. Tilstanden: at være logget af 5. Tilstanden: at adgangen til data er lukket effektivt 1(a). Når en bruger skal foretage login på et it-system (i traditionel forstand), sker det ved, at brugeren afgiver noget, som kun brugeren er i besiddelse af, fx en adgangskode, og dernæst klikker på en login-knap på it-systemets brugergrænseflade, eller trykker på Enter-tasten. 1(b). Brugeren kan i nogle tilfælde foretage login blot ved fx at klikke på en knap (uden at afgive oplysninger så som adgangskode). Eksempler på dette følger senere i teksten. 2. Brugeren er logget på it-systemet, når brugeren har foretaget et succesfuldt login ved metoden beskrevet i 1(a) eller 1(b), og der er etableret adgang til at hente, inddatere eller slette data i it-systemet. 3. Brugeren foretager log-ud, når brugeren nedlægger den etablerede adgang til at kunne hente, inddatere eller slette data i it-systemet. Det sker typisk ved, at brugeren klikker på en log-udknap på it-systemet brugergrænseflade. 4. Brugeren er logget af it-systemet, når adgangen til at kunne hente, inddatere eller slette data er nedlagt. 5. Brugeren har lukket adgangen til data effektivt, når brugeren er logget ud, og det er sikret, at kun brugeren selv kan genetablere/genåbne adgangen til data. Det vil sige, når en genåbning af adgangen til data kræver, at der foretages et login som beskrevet i 1(a) - ikke 1 (B). Det kan måske virke underligt, at tilstanden i punkt 5 (at adgangen til data er lukket effektivt) ikke er det samme som tilstanden i punkt 4 (at være logget af). Det er en problemstilling, som er særlig relevant i SSO-miljøer, og som forklares i den følgende tekst. 1

3 Scenarie A Følgende figurer viser sekvenser af handlinger fra brugerens side og tilstande i systemer. Figurerne skal læses fra venstre mod højre. Når to handlinger/tilstande er forbundet med en pil, symboliserer det, at den første handling/tilstand automatisk afstedkommer den næste - uden yderligere interaktion fra brugerens side. Figur 1 viser et SSO-miljø, hvor brugeren foretager et login ved at afgive en adgangskode til et itsystem. Brugerens handling har den konsekvens, at brugeren efterfølgende er logget på 3 systemer - selv om brugeren kun har afgivet adgangskoden én gang og til ét system. Figur 1 Det login, som system X foretager på system Y og Z, behøver ikke at indebære nogen udveksling af adgangskode. Typisk sker det ved at system X bekræfter over for system Y og Z, at brugeren aktuelt er logget på system X. Figur 2 viser samme SSO-miljø som figur 1, men nu vil brugeren gerne foretage log-ud. Brugeren foretager et log-ud på ét af systemerne. Handlingen har den konsekvens, at brugeren efterfølgende er logget af alle 3 systemer - selv om brugeren kun har bedt om at blive logget af én gang og på ét system. Figur 2 Dette SSO-miljø begrænser altså det antal gange, brugeren skal foretage login og log-ud. Sådanne SSO-miljøer anvendes typisk internt i virksomheder, hvor medarbejderne har brug for en nem adgang til mange forskellige it-systemer. 2

4 Scenarie B Figur 3 viser en anden type SSO-miljø, hvor brugeren foretager et login ved at afgive en adgangskode. Efterfølgende kan brugeren foretage login på et andet system blot ved at klikke på en knap (uden at skulle afgive adgangskode). Figur 3 Dette SSO virker kun den ene vej, altså kun hvis brugeren starter med at logge på system X. Hvis brugeren starter med at logge på system Y, er det ikke muligt efterfølgende at logge på system X uden afgivelse af adgangskode. Figur 4 viser samme SSO-miljø som i figur 3, men nu vil brugeren gerne foretage log-ud. Brugeren foretager log-ud på det ene system, men i modsætning til scenariet i figur 2 bliver brugeren ikke nødvendigvis logget ud på det andet system. Brugerens log-ud kan have forskellig effekt afhængig af, hvilket system brugeren foretager log-ud på. Figur 4 I dette scenarie er det uklart, hvad der skal til for at foretage login efter at have foretaget et logud. Kræver det afgivelse af adgangskoden eller blot et nyt klik på knappen? Afhænger det af, hvor eller hvordan log-ud blev foretaget? Er situationen anderledes, hvis knappen er utilgængelig (applikation/browser er lukket), eller kan man stadig foretage login ved et klik på knappen, blot man finder frem til den samme applikation/url (internetadresse), hvor knappen er placeret? I dette SSO-miljø kan det være svært for brugeren at gennemskue, om adgangen til data er lukket effektivt, fordi det ikke umiddelbart har noget at gøre med at være logget af. 3

5 Scenarie C Figur 5 viser et SSO-miljø, der har en del lighedspunkter med scenarie B, men set fra brugerens synspunkt kan det fremstå meget anderledes. I dette tilfælde er det valgt at beskrive scenariet ved hjælp af web-sider med knapper, fordi brugeren udelukkende tilgår systemerne via websider. Figur 5 Ligesom i scenarie B får brugeren adgang til et nyt system uden at skulle afgive sin adgangskode. Til forskel fra Scenarie B er der her ikke tale om, at brugeren blot klikker på en knap på system X. Brugeren tilgår selv et helt andet system (Y) og initierer selv et nyt login på system Y. Desuden er der ingen forskel på, hvor brugeren starter med at logge på, så dette SSO vil virke uanset, om brugeren først logger på system X, Y eller Z. Når brugeren er logget på ét af systemerne (X, Y eller Z), er der ikke umiddelbart noget, der fortæller brugeren, at andre systemer kan tilgås uden brug af adgangskode. Systemerne er autonome i forhold til hinanden, selv om de indgår i samme SSO-miljø. Det indebærer, at det enkelte system, fx Y, ikke behøver at kende til eksistensen af de to andre systemer (X, Z). Log-ud kan ske i hvert af de tre systemer uafhængigt af de andre systemer. Afhængigt af hvordan log-ud implementeres, kan det fx have den effekt, at der sker log-ud på alle systemer eller, at der kun sker log-ud på det enkelte system. I dette SSO-miljø er det (ligesom i scenarie B) svært for brugeren at gennemskue, hvornår adgangen til data i et system er lukket effektivt, fordi det ikke umiddelbart har noget at gøre med at være logget af det enkelte system. 4

6 Vejledning af brugeren Når det er svært for brugeren at gennemskue, hvad der skal til, før adgangen til data er lukket effektivt, er det en nærliggende tanke, at brugeren skal vejledes til at udføre de rigtige handlinger. Men det kan være en udfordring. Et SSO-miljø kan inkludere forskellige serviceudbydere, forskellige dataansvarlige, forskellige systemer og brugere med forskelligt niveau af it-kompetencer. Det kan være en udfordring eller helt umuligt at lave en vejledning, som alle serviceudbyderne og dataansvarlige er enige om, som kan forstås af alle brugerne, og som samtidig passer til alle systemerne. Den dataansvarliges ansvar De udfordringer, som brugeren står over for i SSO-miljøet, kan udgøre en risiko for den dataansvarlige. Den dataansvarlige skal blandt andet træffe sikkerhedsforanstaltninger mod, at oplysninger hændeligt eller ulovligt tilintetgøres, fortabes eller forringes, samt mod at de kommer til uvedkommendes kendskab 1. Dette ansvar ændres/overføres ikke, blot fordi et itsystem bliver omfattet af et SSO-miljø. Hvis brugeren fx ikke kan sørge for, at adgangen til data er lukket effektivt, kan det indebære en risiko for uvedkommendes adgang til at se og ændre i data. Den dataansvarliges ansvar for at beskytte data ender ikke ved det punkt, hvor der er etableret en adgang til data. Den dataansvarlige skal sikre, at adgangen til data kan lukkes effektivt. Hvis en medarbejder ansat hos en dataansvarlig behandler personoplysninger for den dataansvarlige, er det også den dataansvarliges ansvar at sikre, at adgangen til data bliver lukket effektivt. Hvis en medarbejder ansat hos en databehandler behandler personoplysninger for en dataansvarlig, vil den dataansvarlige også i denne situation have ansvaret for at sikre, at adgangen til data bliver lukket effektivt. Brugerens og den dataansvarliges risici Hvis det er uklart, hvornår adgangen til data er lukket effektivt, indebærer det en risiko for, at uvedkommende får adgang til at hente, inddatere eller slette data. Når der er tale om et SSOmiljø, kan det forøge risikoen, fordi en sikkerhedsbrist her kan påvirke adgangen til flere systemer i stedet for kun ét system. Eksempler på udfordringer og risici: Et klik på en knap, hvor der står "log-ud", medfører log-ud, og brugeren informeres om, at han/hun nu er logget af, men brugeren er ikke logget af alle systemer i SSO-miljøet. o Risiko: Brugeren udfører ikke de handlinger, som er nødvendige, før adgangen til data er lukket effektivt på alle systemer. Et klik på en knap, hvor der står "log-ud", medfører log-ud, og brugeren informeres om, at han/hun nu er logget af. Hvis brugeren umiddelbart efter foretager login på ét af systemerne under SSO, så kræves der ikke afgivelse af adgangskode. o Risiko: Brugeren udfører ikke de handlinger, som er nødvendige, før adgangen til data er lukket effektivt på alle systemer. 1 Uddrag af persondatalovens 41, stk. 3 5

7 Brugeren bevæger sig rundt i en applikation og kommer derfor væk fra det sted, hvor logud-knappen befinder sig. Brugeren kan ikke finde tilbage igen. o Risiko: Brugeren har svært ved at foretage ordentligt log-ud og vælger i stedet at lukke applikationen, men det sikrer ikke, at adgangen til data er lukket effektivt. Det er uklart for brugeren, om lukning af applikation, browser eller browserfaneblad (uden brug af log-ud-knap) vil være tilstrækkeligt til sikring af, at adgangen til data er lukket effektivt. o Risiko: Brugeren vælger måske én af disse løsninger (frem for brug af log-ud-knap), fordi de er nemme, og fordi det i andre systemer har en effekt svarene til log-ud. Brugeren indretter dermed ikke sine handlinger efter den reelle risiko i det konkrete system. Det er uklart for brugeren, om sessions-timeout er tilstrækkeligt til sikring af, at adgangen til data er lukket effektivt. o Risiko: Brugeren kan ikke vurdere risikoen ved at glemme eller undlade at foretage log-ud, og indretter ikke sine handlinger efter den reelle risiko. Vejledningen til lukning af adgang er kompliceret, tager lang tid at følge, eller er ikke tilpasset brugerens it-kompetencer. o Risiko: Brugeren kan ikke huske vejledningen fra gang til gang, og finder den besværlig/tidskrævende at følge. Brugeren vælger i stedet at gøre det, som instinktivt virker rigtigt, og dette sikrer ikke, at adgangen til data er lukket effektivt. Vejledningen til lukning af adgang vises kun på tidspunktet for login, men ikke ved log-ud. Når der senere skal foretages log-ud, har brugeren glemt vejledningen eller kan ikke fremfinde den. o Risiko: Brugeren kan ikke huske vejledningen og udfører derfor ikke de nødvendige handlinger til sikring af, at adgangen til data er lukket effektivt. Der tilføjes nye systemer til SSO-miljøet, hvorved det samme login nu giver adgang til mere. Det sker uden brugerens viden. o Risiko: Før tilføjelsen af nye systemer til SSO-miljøet var det måske mindre kritisk, om adgangen til data var lukket effektivt, når brugeren forlader computeren. Brugeren er ikke er klar over, at der er tilføjet nye systemer, og bliver måske heller ikke klar over det under login, fordi de nye systemer ikke benyttes. Brugerens handlinger følger ikke med udviklingen, fordi brugeren ikke er klar over, at risikoen er forøget ved, at hans/hendes login nu giver adgang til flere data. 6

8 God praksis Udfordringerne, som denne tekst har givet eksempler på, kan løses på flere måder og ofte i en kombination af systemets indretning og vejledning til brugeren. Man skal dog være opmærksom på begrænsninger. Brugeren kan have begrænsede it-kompetencer, som gør det svært for dem at følge tekniske vejledninger. Desuden kan en meget besværlig log-ud-proces medføre, at brugeren i frustration eller på grund af tidspres undlader at følge vejledningen. Derfor er det særligt relevant at se på indretningen af systemet med fokus på at gøre det nemt for brugeren at beskytte data uden at skulle følge lange, komplicerede vejledninger. Nedenstående punkter er relevante at overveje for den dataansvarlige og for dem, der udvikler SSO-løsninger. Punkterne dækker ikke alt, som kan være relevant i forhold til SSO-løsninger, idet der fokuseres på de problematikker, som er beskrevet i denne tekst. 1. Log-ud tænkes ind i systemerne fra starten. Hvis ikke det sker, kan en senere tilpasning af systemerne betyde store omkostninger. Denne situation kan gøre det fristende at løse problemet på en billigere måde, nemlig udelukkende ved vejledning af brugeren. Men, som beskrevet, kan det være utilstrækkeligt at løse alle udfordringerne ved at vejlede brugeren. 2. Alle parter, som kommer til at anvende samme SSO-miljø, aftaler fra starten, hvem der har ansvaret for at udvikle og implementere et log-ud, som sikrer, at adgangen til data er lukket effektivt, og som dækker hele SSO-miljøet. Et fælles sikkert log-ud. 3. Det er altid tydeligt for brugeren, hvis der siden sidste login er sket ændringer til SSOmiljøet og dermed en ændring i risikoen ved, at adgangen til data ikke er lukket effektivt. Det kan fx ske ved at: Brugeren får besked, hvis der siden sidste login er tilføjet et nyt system til SSOmiljøet, således at samme login nu giver adgang til flere fortrolige/følsomme data, eller brugeren aktivt skal tilvælge, hvilke systemer et login skal give adgang til. 4. Den dataansvarlige gør det nemt for brugeren at sikre effektiv lukning af adgang til data. Det indbefatter: At gøre det tydeligt for brugerne, hvilke data/systemer der er etableret adgang til. At gøre det tydeligt (visuelt) for brugerne, hvornår adgangen til data er lukket effektivt og, hvornår den ikke er. 5. Systemerne afstemmes til forventningerne. Brugerens forventninger skal helst passe til virkeligheden. Hvis brugerne forventer, at handlingen "at foretage log-ud" er ensbetydende med, at man efterfølgende har en tilstand, hvor adgangen til data er lukket effektivt, så bør et klik på "log-ud" også have denne forventede effekt. Alternativt bør log-ud-knappen hedde noget andet. 6. Log-ud-knap er altid tilgængelig og nem at finde, så længe brugeren ikke er logget af. 7. Systemerne indrettes således, at brugeren, uden at følge vejledninger, nemt og intuitivt kan sikre, at adgangen til data er lukket effektivt. 7

9 8. Hvis indretning af systemerne ikke er tilstrækkelig, og det er nødvendigt med en vejledning af brugeren, så bør følgende sikres: Vejledningen er kort og klar. Vejledningen indeholder ikke begreber eller forklaringer, som er vanskelige at forstå. Vejledningen gives/vises på det rigtige sted og på det relevante tidspunkt, fx at en vejledning om lukning af adgang til data vises, når brugeren foretager log-ud. Vejledningen vises på en sådan måde, at brugeren ikke kan undgå at se den, uafhængigt af hvordan systemet benyttes. Vejledningen tilpasses alle brugernes it-kompetencer. Der er kun én vejledning, og hvis den følges, vil det resultere i, at adgangen til data er lukket effektivt, uanset hvilke systemer brugeren har benyttet, mens brugeren var logget på. 9. Systemerne indrettes, så der er taget højde for, at brugeren kan glemme at foretage logud. Som minimum ved følgende tiltag: Der er automatisk timeout på sessionen, hvorved en rimelig kort periodes inaktivitet fra brugers side resulterer i, at adgangen til data er lukket effektivt. Lukning af applikation/browser (uden brug af log-ud-knap) bør resultere i, at adgangen til data er lukket effektivt. Hvis ikke det er tilfældet, bør sessionens automatiske time-out sikre, at en rimelig kort periodes inaktivitet fra brugers side resulterer i, at adgangen til data er lukket effektivt. 10. Behovet for at kunne spærre adgange i SSO-miljøet er tænkt ind fra starten. Følgende kan være relevant at vurdere: Skal det være muligt at spærre den samlede adgang til alle systemer i SSO-miljøet, og hvem skal kunne udføre det? Skal det være muligt at spærre individuelle adgange i SSO-miljøet, og hvem skal kunne udføre det? Det er især relevant ved flere dataansvarlige i samme SSOmiljø. Hvis ikke adgange kan spærres individuelt, hvad kan konsekvensen så være, ved fx sikkerhedsbrister på enkelte systemer eller eksponeret adgangskode, med videre? Det kan skabe en interessekonflikt, hvis fx en sikkerhedsbrist opstår på ét system, mens brugeren er dybt afhængig af et andet system og derfor ikke ønsker at spærre den samlede adgang. Hvordan instrueres brugeren i spærring af adgang ved fx sikkerhedsbrister eller eksponeret adgangskode, med videre? Det er uheldigt, hvis kun den samlede adgang kan spærres, og én dataansvarlig instruerer brugeren til at spærre adgangen ved sikkerhedsbrist, mens en anden dataansvarlig giver en konfliktende instruks. dt@datatilsynet.dk (+45)