Behörighetssystem. Ska kontrollera att ingen läser, skriver, ändrar och/eller på annat sätt använder data utan rätt att göra det

Transkript

1 Behörighetssystem Ska kontrollera att ingen läser, skriver, ändrar och/eller på annat sätt använder data utan rätt att göra det

2 Systemet måste kunna registrera vilka resurser, d v s data och databärande kanaler med begränsad tillgång som finns vilka användare, processer m m som kan begära tillgång till resurser vilken rättighet som gäller för alla tänkbara kombinationer av resurs och begärd tillgång

3 Grundproblem: Att effektivt ange rättigheter Vi kan inte manuellt skriva in detaljerade rättigheter för varje resurs i datorn Vi kan inte manuellt ange för varje användare exakt vad den användaren får göra Så vi behöver generella strukturer och regler

4 Att hantera rättigheter Vi behöver en policy för vilka typer av skyddsvärda dataobjekt som finns Vi behöver en policy för vilka användare som får hantera dessa objekttyper och hur varje användare får hantera dem Vi behöver ett sätt ange detta i datorn Vi behöver möjlighet att analysera om det fungerar som avsett

5 Begrepp att arbeta med Användaridentiteter Användargrupper/roller Enskilda dataobjekts identitet Kataloger som samlingsbegrepp för dataobjekt och för identiteter Domäner där detta gäller och fungerar Verktyg för samverkan mellan domäner

6 Om möjligt: Tänk i teoretiska modeller För att skapa och utvärdera behörighetsfunktioner måste vi bestämma Vad är ett brott mot sekretessen? Vad äventyrar tilliten till datas riktighet? Det räcker inte med krav bara utifrån enstaka tillgång till datafält Hänsyn måste tas till informationsflöden Vi behöver mer övergripande regler

7 Grundbegrepp Subjekt är den aktiva parten, en användare, en process el. dyl. Objekt är den passiva parten, en fil, en skrivare el. dyl. Vi förutsätter hierarkisk informationsklassning

8 Hierarkisk organisation Avd.-chef 3 Projektledare Projektledare Projektledare 2 Anställd Anställd Anställd Anställd Anställd Anställd 1

9 Regler för hierarkier Högre nivåer dominerar lägre. D. v. s. det som är tillåtet på en nivå är också tillåtet för dem på högre nivå. Alltså är rättigheter på en nivå unionen av det som gäller på underliggande delar och det som tillkommit på denna nivå.

10 Exempel: Bell-LaPadula Sekretess (vem får se vad) Hierarkiska nivåer och partiell ordning Subjekt (användare, process) Objekt (fil, skrivare, nätport) S i är den högsta nivå som subjekt i får läsa från O j är sekretessnivån för objekt j

11 Bell-LaPadula Enkla säkerhetsregeln: Subjekt i får läsa objekt j omm S i O j *-egenskapen Subjekt i får skriva i objekt j omm S i O j. Alla aktuella rättigheter listas i matrisen M Inga rättigheter i M bryter ovanstående regler

12 Skrivregel för att få sekretess? Antag att Alice får läsa fil X, men Bob får det inte Bob får läsa fil Y Scenario om vi inte har skrivregel: Bob lurar Alice att köra ett program som kopierar innehållet i X till Y Så Alice får inte ha rättighet att skriva något som kan läsas under hennes nivå!

13 Bell-LaPadula Så långt har vi en statisk modell Resultat: Subjekt kan bara skriva data på sin egen nivå eller en högre nivå. Exempel: En befälhavare kan aldrig skriva ett enkelt PM till sina underlydande. Lösning 1: Skapa en aktuell nivå C i S i. Man kan logga in på låg nivå. C i höjs automatiskt då man läser på högre (tillåten) nivå Lösning 2: Skapa tillförlitliga subjekt som får klassa data till lägre nivå

14 Annat exempel: Biba dataintegritet (kan jag lita på data) nivå anger grad av tillförlitlighet Subjekt i får skriva i objekt j omm S i O j Subject i får läsa objekt j omm S i O j.

15 Och så arbetsområden: Hierarkier räcker inte. En flygmajor har inte rätt att läsa en infanterikaptens data. Ortopedens chefsläkare får inte automatiskt skriva dagjournal för psykiatripatient. Vi behöver ändå veta vilka informationsflöden som är tillåtna, utan att specificera det för varje par av filer Vi måste också hantera om överlapp av områden är tillåtet eller inte.

16 Inför kategorier! Avdelning Grön+Blå Grön+Röd Blå+Röd Grön Blå Röd

17 Verktyg Så långt teori för analys Men hur registrerar man det här? Och hur får man överblick? Tänk behörighetsmatris!

18 Behörighetskontrollsmatris Översikt över vad subjekt får göra med objekt Har en rad (eller kolumn) per användare, = subjekt Har en kolumn (eller rad) per fil, = objekt Gleshet gör att man aldrig lagrar så i praktiken Data 1 Data 2 Prog. 1 Prog. 2 Alice RW E Bob R RW RWE Carol R E David RW R E RWE Eve R RE

19 Lagring av behörighetsdata Mekanismer: Access Control Lists, ACL listar per objekt vilka rättigheter registrerade subjekt har till objektet Specialfall: Permission bits (skyddsbitar) Tickets, capabilities, attributcertifikat ( biljettsystem ) listar per subjekt vilka rättigheter biljettens ägare har till listade objekt

20 Skyddsbitar (Permission Bits) Mycket enkel teknik Rättigheter och subjektstyper måste tillhöra få, förutbestämda möjliga värden = Ofta alltför grov indelning Effektivt Inga separata listor. Rättigheter registreras med övriga grunddata för varje objekt

21 Skyddsbitar Tre sorters subjekt per objekt: Ägare Grupp Övriga Tre sorters rättigheter per subjektstyp läs skriv exekvera

22 Skyddsbitar Tre grupper om tre bitar, en grupp per subjekttyp, en bit var för läs, skriv och exekvera. 0 betyder att subjektstypen inte har rättigheten 1 betyder att subjektstypen har rättigheten

23 Skyddsbitar Exempel: Fil Ägare Grupp Övriga r w e r w e r w e Prog Prog1 kan läsas och skrivas av ägaren, exekveras även av sin grupp och övriga användare kan inte göra något med filen Data Alla kan läsa Data1, bara ägaren och gruppen kan skriva

24 Access Control Lists (ACLs) Lätt att förstå och därmed administrera Lätt att ta reda på vem som har vilken sorts tillgång ett objekt Bra vid distribuerade system att rättigheter registreras där det skyddade objektet är Kan vara ineffektivt. Varje begäran från användare kan kräva sökning i lång lista.

25 Utveckling av ACL-grunder Grupper för att få effektivare listor Regler för vad som gäller om någon (genom grupper) har två olika rättigheter Access: None ger möjlighet att snabbt skapa mindre grupper ur existerande Kan lätt utvidgas till databas för RBAC (Roll Based Access Control) Särskilda regler för systemadministratör

26 Rättighet för användare eller program? Användare ska ofta inte ha direkt tillgång till dataobjekt (t. ex. databaser). Lösningen är att ge hanteringsprogram rättigheter till filen, och användaren rättighet att köra programmet Men en del system tillåter bara att rättigheter registreras för användare Lösning i UNIX etc. är att använda SUID.

27 Rättighet via program Fil1: Program1, RW Program1: Gruppenallaanvändare, E eller Fil1: Program1ägare, RW Program1: Owner = Program1ägare; SUID; Gruppenallaanvändare, E Ingen kan logga in som Program1ägare

28 Subjekt-orienterat Biljetter, certifikat, listor o s v Upplösningen kan vara hög (även små objekt kan få detaljspecificerat skydd) Lätt att ge rättigheter till nya subjekt Men certifikat kan kopieras och kräver därför kontroll att anroparen är certifikatsägaren Svårt att spåra och återkalla rättigheter

29 Distribuerade system? Behörighetskontroll sköts i botten av säkerhetskärna, reference monitor Inget subjekt har tillgång till något objekt utom via kärnan Om tjänster och/eller data ligger på flera datorer, måste flera kärnor samverka

30 Dator, distribuerat eller nät? Om bara en OS- kärna är inblandad, så har vi endatorsystem, oberoende av antal processorer o. dyl. Om flera OS-kärnor är inblandade, men de känner till varandra, varandras tjänster och varandras användare, så har vi ett distribuerat system. Kontakter med okända faller under metoder för nätsäkerhet. Sandlådor för appar ger viss distributionsmöjlighet ovanför egentliga kärnan

31 Distribuerade systems säkerhet Punkter att hantera: Global policy Lokal tillämpning av policy Autenticering, var? Av vem? Delegation av rättigheter Avgränsning: vad gäller var som global/ lokal

32 Global policy Är det verkligen ett, sammanhållet system? Om ja, så ska samma policy gälla överallt. Så vad gör jag om lokala klasser och regler inte stämmer? Om nej, var lägger vi gränserna? Per dator, per avdelning, per lokalkontor, eller? Om vi verkligen har en gemensam policy, så behöver vi också gemensamma behörighetsdata, åtminstone på en övergripande nivå

33 Lokal tillämpning En åtgärd kan vara tillåten enbart efter individ-autenticering. En åtgärd kan vara tillåten för alla anrop som kommer inifrån systemet. En åtgärd kan vara tillåten för alla som kan anropa systemet. Man kan välja att lita på att anropande adress redan kontrollerat rättighet.

34 Global kontra lokal miljö Finns det brandväggar, protokoll och andra begränsningar, som gör att användaren får olika villkor mellan jobb i lokal miljö och i global? Vad är "lokal" och "global i just detta system? Var finns gränserna till systemet som helhet? Finns det olika globalitetsnivåer?

35 Delegation av rättigheter Finns anropande användare registrerad lokalt? Skickas bevis på rättigheter med anropet? Finns det en lokal användare, som fungerar som ombud med rättigheter?

36 Verktyg Katalogsamordning Hierarkisk registrering typ X.500 Kommunikation mellan katalogenheter, som LDAP Windows har under åren skapat många varianter på hur man överför information om ID och rättigheter mellan datorer, men detaljer i sådana protokoll hör inte till kursen XML kan vidarebefordra rättighetsdata

37 Attribut-certifikat Fungerar som capability, d. v. s. biljett Beskriver i standardiserat format vilka rättigheter en användare har Blanda inte ihop dessa certifikat med nyckelcertifikat!!!!

38 Användarautenticering Enbart avsändaradress? I varje del av systemet? Single Sign On?

39 Avsändaradress Adresser är triviala att förfalska om man tagit över en kommunikationsnod Adressförfalskning är ännu enklare, om mottagaren aldrig skickar ett svar till avsändaradressen eller svaret inte stör förfalskarens avsikter (d v s svaret inte innehåller information som förfalskaren behöver, rätt adressägare inte slår larm eller annat sådant) Adresser kan autentiseras i sig, men de kan ändå inte användas som grund för rättigheter annat än då man litar helt på sändande dator

40 Autentisering enbart lokalt Nackdelar: Känslig information måste överföras En global identitet = Katastrof om den tas över av någon Lokala identiteter = Besvärligt för användaren Fördel: Låg säkerhet i en systemdel påverkar inte säkerheten i övriga systemet

41 Protokoll för single sign-on Autenticering av användaren görs en enda gång centralt vid påloggning. Varje användare måste stå för säkerheten lokalt för lösenord/nyckel Alla andra i systemet måste lita på att den som vet värdet på en nyckel är legitim innehavare av nyckeln Den centrala servern är en kritisk flaskhals

42 Single Sign-on Utvecklingshistorien innehåller flera exempel: Kerberos,.NET passport (utvecklat till Windows Live ID), Liberty Alliance-projektet, X500 och 509 mm. Grund för alla: Man autentiseras av en enda tillförlitlig part, som lämnar garantier till alla andra. Samtliga förutsätter lösenord och kryptering. Kerberos, som är bas och inspiration för de flesta, använder symmetrisk kryptering och kunskap om nycklar som bevis för identitet. Asymmetrisk kryptering vinner terräng idag.

43 Man-in the-middle Alice och Bob tror att de kommunicerar direkt med varandra I själv verket kommunicerar de via Eve Hej Bob, Alice här! Hej Bob, Alice här! Alice Eve Bob Hej Alice, Bob här! Hej Alice, Bob här! Dags att diskutera nätsäkerhet och krypto