Rettighedsstyring i federeret miljø. Jesper Gerved

Transkript

1 Rettighedsstyring i federeret miljø Jesper Gerved Kongens Lyngby 2008

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax

3 Abstract Technologies such as web services and SOA have contributed to the development of information technology (IT), making integration of IT systems across organisations significantly easier in terms of implementation. As a result, a number of barriers relating to the establishment of cross-disciplinary systems have been broken down. The increased possibilities of cooperation across several organisations and system interaction, however, give rise to new security related issues, since the need for strong management of rights across IT systems also increases. Accordingly, an access control model is needed which is easily integrated across company boundaries while also being suited for handling systems far more dynamic than previously. The security level should suffer no consequences, though, considering that the increased interaction at the same time increases the need for protection of confidential data. In order to establish which model would be best suited for handling rights, this project has, on the basis of two very different approaches, the role based (RBAC) and the attribute based (ABAC), performed a theoretical assessment of which model best supports contemporary and, in particular, future needs. As a basis for the assessment, a detailed technical review has been performed for each of the two models of the most common scenarios in connection with use of an access control model. The review illustrates the theoretical advantages to using the mindset behind ABAC as opposed to the more traditional RBAC. It is, however, also evident that with ABAC representing a relatively new way of thinking, documentation of this approach is far more incomplete than that of RBAC. In the report, it is concluded that ABAC is better suited for access management across numerous organisations and that ABAC supports the flexibility and dynamics necessary for technologies such as SOA and web services - at least if an optimal situation is desired. Still, ABAC remains a new model, and practical experience is limited. Additionally, from my work in PricewaterhouseCoopers, I have learned that in connection with actual implementation, certain issues may arise which are not always apparent in relation to a theoretical review. This means that the ABAC approaches may have to be employed in an adjusted form, and in this connection it may be a good idea to combine the mindsets behind RBAC and ABAC. In closing, suggestions have been made in terms of further research which can be performed in support of and as a test of the results of this report. iii

4 Resume Teknologier som web-services samt SOA-begrebet har været medvirkende til at udvikle informationsteknologien, så integrering af it-systemer på tværs af organisatorisk skel er blevet væsentligt simplere at implementere. Dette har nedbrudt en række barrierer vedrørende etablering af tværgående systemer. De øgede muligheder for samarbejde på tværs af flere organisationer samt systemmæssig interaktion medfører dog også nye sikkerhedsmæssige problematikker, da behovet for en stærk styring af rettigheder på tværs af it-systemerne øges. Derfor er der behov for at finde en rettighedshåndteringsmodel, som er nem at integrere på tværs af virksomhedsgrænser, samtidig med at den er velegnet til at håndtere systemer, der er langt mere dynamiske end tidligere. Sikkerhedsniveauet skal dog være uændret, da den øgede interaktion medfører øget behov for beskyttelse af fortrolige data. For at finde frem til, hvilken model der bedst udfører rettighedshåndteringsopgaven, har dette projekt på grundlag af to vidt forskellige tilgange - den rollebaserede (RBAC) samt den attributbaserede (ABAC) - foretaget en teoretisk evaluering af, hvilken model der bedst understøtter tidens og ikke mindst fremtidens behov. Som grundlag for evalueringen er der for hver af de to tilgange foretaget en detaljeret teoretisk gennemgang af de mest almindelige scenarier i forbindelse med anvendelse af en rettighedshåndteringsmodel. Gennemgangen viser fordelene ved at anvende tankegangen bag ABAC frem for den mere traditionelle RBAC, men det fremgår ligeledes, at ABAC er en forholdsvis ny tankegang, og at dokumentationen af denne derfor er langt mere ufuldstændig end dokumentationen af RBAC. Rapporten konkluderer, at ABAC er bedre egnet til rettighedsstyring på tværs af flere organisationer samt understøtter den fleksibilitet og dynamik, teknologier som SOA samt web-services efterspørger. ABAC er dog fortsat en ny model, og praktisk erfaring er en mangel. Fra mit praktiske arbejde hos PricewaterhouseCoopers har jeg ydermere fået indsigt i, at der i forbindelse med en faktisk implementering kan være nogle problemstillinger, som ikke umiddelbart kommer til udtryk i forbindelse med en teoretisk gennemgang. Dette betyder, at der kan være behov for at anvende ABAC-tilgange i en lettere tilpasset form. I den forbindelse kan det være en idé at kombinere tankegangen bag RBAC og ABAC. Afslutningsvis er der opstillet forslag til yderligere research, der kan foretages for at underbygge samt afprøve denne rapports resultater. iv

5 Forord Dette projekt er udført som afsluttende eksamensprojekt på civilingeniørstudiet på Danmarks Tekniske Universitet. Projektet er udført ved Institut for Informatik og Matematisk Modellering, Computer Science & Engineering - Safe and Secure IT Systems under vejledning af Christian D. Jensen. Projektets omfang repræsenterer 40 ECTSpoint og er udført i perioden fra den 9. november 2007 til den 4. juli Jeg vil meget gerne benytte lejligheden til at takke min vejleder, Christian D. Jensen, for deltagelse i dette projekt og ikke mindst for gode råd og vejledning undervejs i processen. Derudover vil jeg gerne rette en stor tak til mine kollegaer hos PricewaterhouseCoopers, for værdifuld vejledning samt korrekturlæsning. Kongens Lyngby, den 4. juli 2008 Jesper Gerved s v

6 Læsevejledning I rapporten er der anvendt fagudtryk og forkortelser. Forkortelserne introduceres første gang sammen med det udtryk, de forkorter. Fagudtrykkene derimod defineres kun i begrænset omfang, da læserne af dette projekt formodes at have grundlæggende kendskab til emnet og herved kendskab til de mest grundlæggende begreber. I forbindelse med Der er benyttet opløftede tal ( 1 ) som henvisning til fodnoter, der vises nederst på den aktuelle side. Fodnoterne er primært anvendt til at angive det engelske udtryk i de tilfælde, hvor der har været usikkerhed omkring, hvorvidt den anvendte oversættelse er alment kendt. Der er ligeledes anvendt tal i kantede parenteser [1] eller [1 - afsnit x], hvor [1] henviser til litteraturlisten bagerst i rapporten mens [1 - afsnit x] tilsvarende henviser til litteraturlisten, men blot samtidig angiver mere eksakt hvilket afsnit i den pågældende kilde der henvises til. Rapporten er overordnet inddelt i seks kapitler med tilhørende underafsnit: Kapitel 1 Den grundlæggende problemstilling beskrives, hvorefter der foretages en afgrænsning af projektet. Ydermere beskrives fremgangsmåden for det udførte arbejde, hvor bl.a. brugen af kilder gennemgås i en kildekritik. Kapitel 2 Der stilles skarpt på behovet for it-sikkerhed, hvor fokus er på de elementer, som er vigtige i forbindelse med dette projekt om rettighedsstyring. Kapitel 3 Der fokuseres på den udvikling, som er sket i virksomhederne, teknologien samt den gældende lovgivning gennem de seneste år. Denne beskrivelse indikerer, hvilke elementer en god rettighedsstyringsmodel bør understøtte og kridter herigennem banen op for den afsluttende evaluering. Kapitel 4 Den rollebaserede adgangskontrolmodel (RBAC) 1 beskrives i grundlæggende termer. Ydermere fokuseres der på, hvordan denne model anvendes samt vedligeholdes i praksis. 1 På engelsk: Role-Based Access Control vi

7 Kapitel 5 Den attributbaserede adgangskontrolmodel (ABAC) 2 beskrives i grundlæggende termer. Ydermere fokuseres der på, hvordan denne model anvendes samt vedligeholdes i praksis. Kapitel 6 Den rollebaserede model (RBAC) fra kapitel 4 samt den attributbaserede model (ABAC) fra kapitel 5 evalueres op mod hinanden med udgangspunkt i den udvikling, som er beskrevet i kapitel 3. Kapitel 7 Projektets konklusion beskrives. Ydermere foretages en perspektivering samt gives forslag til supplerende arbejde, som kan udføres for en endnu mere dybdegående forståelse af den valgte model. God læselyst! 2 På engelsk: Attribute-Based Access Control vii

8 Indhold Side Abstract Resume Forord Læsevejledning iii iv v vi Kapitel 1 Indledning Problemfelt Problemformulering Afgrænsning Metode Baggrundsinformation Modelbeskrivelse Evaluering Kildekritik 4 Kapitel 2 Sikkerhed i IT-systemer Rettighedsstyring Adgangskontrol Klassiske adgangskontrolmodeller Indførelsen af en abstraktionsmodel 10 Kapitel 3 It til forretningsunderstøttelse Business-driver Kunderne Samarbejdspartnerne 15 viii

9 3.1.3 Medarbejderne Backoffice Sammenfatning Teknologi-driver Autentifikation på tværs af organisationer SOA Sammenfatning Compliance-driver Sarbanes-Oxley DS Sammenfatning 24 Kapitel 4 RBAC Arkitektur NIST RBAC Basis RBAC Hierarkisk RBAC Statisk funktionsadskillelse Dynamisk funktionsadskillelse Anvendelsen af RBAC-model Modeladministration Rettighedsadministration Kontrol og opfølgning 40 Kapitel 5 ABAC Arkitektur Yuan og Tongs ABAC-model Definition af attributter Valg af attributter Regelsæt Anvendelsen af ABAC-model Modeladministration 45 ix

10 5.3.2 Rettighedsadministration Kontrol og opfølgning 49 Kapitel 6 RBAC vs. ABAC Kortlægning af model på tværs af organisationer Administration Administrationens placering Tilpasning til ændringer Minimering af fejl Tidsmæssige besparelser Forskellige adgangsbehov Nuanceret adgangstildeling Ukendte adgangsbehov Efterlevelse af compliancekrav Funktionsadskillelse Uafviselighed 58 Kapitel 7 Konklusion Perspektivering Delvis ABAC implementering Eksempel på delvis ABAC implementering Fremtidssikring Forslag til videre arbejde 61 Litteratur 63 x

11 Figurer Side Figur 1.1 Model- og rettighedsadministration 4 Figur 2.1 Forholdet mellem fortrolighed, integritet og tilgængelighed [24]. 6 Figur 2.2 Adgangskontrolforløb [13 - figur 4.2]. 8 Figur 2.3 Tildeling af rettigheder direkte til brugerne. 10 Figur 2.4 Abstraktion vha. roller. 11 Figur 2.5 Tildelinger af rettigheder direkte til brugerne. 12 Figur 2.6 Tildeling af rettigheder til brugerne via roller. 13 Figur 3.1 Værdikæde med interessenterne i mælkeproduktion. 16 Figur 3.2 Interessenternes adgange til virksomhedens it-systemer 18 Figur 3.3 Kontrolmiljø. 21 Figur 3.4 Compliance vejviser [16 - figur 6] 22 Figur 4.1 RBAC-arkitektur. 25 Figur 4.2 Referencemodellens opbygning jf. [10 - figur 7] 26 Figur 4.3 RBAC-relationer jf. [9- figur 1.3]. 27 Figur 4.4 RBAC-tildelingsmuligheder. 27 Figur 4.5 Basis RBAC jf. [10 - figur 1]. 28 Figur 4.6 Hierarkisk RBAC. 29 Figur 4.7 Livscyklus for model. 31 Figur 4.8 Elementer som skal kombineres ved indførelse af RBAC-model. 32 xi

12 Figur 4.9 Livscyklus for ansættelsesperiode. 34 Figur 4.10 Rettighedsadministrationsproces ved ansættelse og reorganisering. 35 Figur 4.11 Rettighedsadministrationsproces ved systemændring. 37 Figur 4.12 Rettighedsadministrationsproces ved indførelse af nyt system. 38 Figur 4.13 Rettighedsadministrationsproces ved orlov samt pensionering. 39 Figur 4.14 Rettighedsadministrationsproces ved afskedigelse. 40 Figur 5.1 ABAC-arkitektur. 42 Figur 5.2 ABAC-Rettighedsadministrationsproces. 47 xii

13 Kapitel 1 Indledning Et af de vigtigste aktiver, i de fleste virksomheder så snart de når en vis størrelse, er itsystemerne. Dette skyldes, at it-systemer er velegnet (til at placere) som et centralt element, der binder virksomhedens forskellige aktiviteter sammen. Denne udbredte anvendelse af it, har den effekt, at den kan understøtte centrale forretningsprocesser, så de relevante medarbejdere ved brugen af it, kan udføre deres del af forretningsprocessen. At it anvendes til at understøtte forretningsprocesser medfører, at virksomhedernes forretningsdata er placeret på it-systemerne. Det er derfor nødvendigt at sikre it-systemerne mod eksterne såvel som interne trusler. En af de mest fundamentale mekanismer til beskyttelse af it-systemer er anvendelsen af adgangskontrol. Anvendelsen af adgangskontrol på it-systemer er et begreb, der har eksisteret i flere årtier. Der er dog med tiden sket en modning af adgangskontrollen, idet der er blevet introduceret modeller der nemt og hurtigt kan tildele nuancerede adgangsrettigheder [9 - afsnit 1]. Der har gennem årene været foreslået samt anvendt forskellige adgangskontrolmodeller. Men siden starten af 1990 erne har anvendelsen af roller som abstraktion i forbindelse med håndtering af adgangsprivilegier, været meget omdiskuteret i litteraturen [9 - afsnit 1]. Begrebet rollebaseret adgangskontrol (RBAC) blev beskrevet første gang af Ferraiolo & Kuhn i 1992 [8]. Siden har flere forfattere ytret sig om netop dette emne [8], [9], [10], [14], [18], [21], [26], [27]. Tankegangen bag RBAC anvendes i mange systemer, men typisk i en tilpasset og mere lempelig form, da RBAC i nogle tilfælde er for omfattende og besværlig at implementere i dens fulde form. I de seneste år er der dog igen kommet fokus på adgangskontrolmodeller, da virksomhedernes øgede samarbejde på tværs af organisationer samt introduktionen af den serviceorienterede arkitektur 3 (SOA). Målet er en fælles SOA-begrebsmodel [19], [32], og betyder, at der er identificeret en række uhensigtsmæssigheder ved RBAC. 1.1 Problemfelt Problemfeltet for dette speciale, bygger på den udfordring der er forbundet med at håndtere brugers rettigheder i it-miljøer, der går på tværs af organisatoriske skel. Det er vigtigt at tildele brugerne de rettigheder som skal til, for at de kan udføre deres arbejde. Samtidig er det også vigtigt at holde et højt it-sikkerhedsniveau, hvilket kan opnås ved, 3 På engelsk: Service-Oriented Architecture 1

14 at den enkelte bruger får så få rettigheder som muligt, dog uden at blive hæmmet i udførelsen af sit job. Samarbejde på tværs af organisationer er langt mere udbredt end tidligere, hvor der i det offentlige f.eks. er behov for information hos andre offentlige instanser, for at kunne træffe de nødvendige afgørelser. Dette har øget udfordringen i at håndtere brugernes rettigheder, idet adgangen til hinandens systemer betyder, at der er behov for, at it understøtter en fælles rettighedshåndtering. Den rollebaserede tilgang til rettighedshåndteringen er ikke umiddelbart velegnet til denne situation, da virksomhederne i fællesskab skal finde en struktur, som passer på tværs af alle de implicerede virksomheder. Dette er yderst vanskeligt grundet virksomhedernes forskellige interne strukturer. Et af de nye alternativer til den rollebaserede tilgang (RBAC), er den attributbaserede tilgang (ABAC), som via sin arkitektur undgår problemstillingen om struktureringen af roller på tværs af flere organisationer. Der er yderligere udfordringer forbundet med at udføre rettighedsstyring, hvor introduktionen af SOA og en fælles SOA-begrebsmodel er en indikation af, at der er behov for en dynamisk og fleksibel rettighedsstyringsmodel [19], [32]. Fokus for dette projekt vil derfor være at undersøge, hvilken model der bedst muligt løser de udfordringer, som virksomhederne står overfor Problemformulering Hvilken af rettighedstildelingsmodellerne RBAC og ABAC understøtter bedst en sikker og pålidelig tildeling af rettigheder, i et miljø som spænder flere organisationer? Afgrænsning Der er i litteraturen forskellige rettighedstildelingsalternativer, men de generelle tendenser peger i retning af modeller, hvor man enten støtter sig til anvendelsen af roller i form af RBAC eller anvendelsen af attributter i form af ABAC. Dette er to modeller, som er meget forskellige og derfor interessante at sammenligne, da de håndterer tingene vidt forskelligt. Baseret på ovenstående vil projektet kun fokusere på disse to modeller, men da der findes flere forskellige fortolkninger af henholdsvis RBAC og ABAC, tager projektet udgangspunkt i NIST s RBAC-standardiseringsforslag [10] samt Yuan og Tongs beskrivelse af ABAC [33]. Begrundelsen for at tage udgangspunkt i netop disse to modeller fremgår af afsnit 1.3, omhandlende kildekritik. Projektets fokus ville være på at evaluere tankegangen bag de to modeller, frem for de små spidsfindige detaljer. 2

15 1.2 Metode For en få en dybere forståelse af dette projekt, kan det være relevant at beskrive opdeling af den resterende del af rapporten. Rapporten er overordnet set opdeles i tre: Baggrundsinformation Modelbeskrivelse Evaluering Hvor det selvfølgelig er beskrivelsen af modellerne samt den efterfølgende evaluering, som danner grundlag for besvarelse af problemformuleringen Baggrundsinformation For at danne et grundlag for beskrivelsen af de valgte modeller er der nogle grundlæggende ting, som skal på plads, såsom forklaring af hvorfor man i det hele taget skal beskæftige sig med rettighedsstyring, begrebet adgangskontrol samt fordelene ved at anvende en abstraktionsmodel. Disse elementer bliver beskrevet i kapitel 2 Sikkerhed i itsystemer. Kapitel 3 It til forretningsunderstøttelse giver også en form for baggrundsinformation, da det beskriver den udvikling, der sker af virksomhedernes struktur samt arbejdsfacon. Endvidere er lovgivningsændringer samt den teknologiske udvikling afgørende faktorer i virksomhedernes arbejdsgange. Kapitlet indikerer, at der er sket meget, siden RBAC blev introduceret i 90 erne, og beskrivelsen fokuserer på de elementer, som bør have indflydelse, når der skal foretages et valg af rettighedsstyringsmodel. Kapitel 3 It til forretningsunderstøttelse er derfor med til at indikere, i hvilken retning udviklingen bevæger sig, hvilket medfører, at kapitlet bliver centralt for evalueringen af RBAC- og ABAC-modellerne Modelbeskrivelse Da der, som beskrevet i afsnit 1.1.2, er flere forskellige fortolkninger af de to adgangskontrolmodeller, vil kapitlerne 4 og 5 indeholde en beskrivelse af de fortolkninger, som er brugt som grundlag for dette projekt. Den grundlæggende beskrivelse af modellerne er selvfølgelig vigtig for dette projekt, men mere relevant er det at undersøge, hvordan modellerne finder anvendelse, da dette er grundlaget for evalueringen af modellerne. For at danne grundlag for en god evaluering er modellernes forskellige anvendelsesmuligheder beskrevet ud fra følgende fire kategorier: Modeladministration Rettighedsadministration Kontrol og opfølgning For bedre at kunne forklare, hvad de to første kategorier dækker over, er det forsøgt illustreret ved hjælp af figur

16 Brugere Model Figur 1.1 Model- og rettighedsadministration Som det fremgår af figur 1.1 har man - uanset om det er RBAC eller ABAC - nogle brugere, som via en model skal tilknyttes nogle rettigheder. Administration, som er forbundet med at indføre, vedligeholde eller slette i den underliggende del af figuren - også kaldet modellen - er det, som beskrives under modeladministrationsafsnittene. Administration i form af indførelse, vedligeholdelse eller afskaffelse af relationerne mellem brugerne og modellen, hvilket er indikeret med røde pile i figuren, beskrives under rettighedsadministrationsafsnittene. I RBAC består denne relation af tilknytningen mellem brugere-roller, mens relationen i ABAC består i at vedligeholde brugernes attributter Der er ifølge lovgivningen også behov for, at der udføres kontrol af, at rettighedsstyringsmodellen afspejler det forventede. Kontrol- og opfølgningsafsnittene vil beskrive, hvordan de to modeller håndterer dette Evaluering Det helt centrale element i denne rapport er at foretage en evaluering af de to modeller, hvilket er udført i kapitel 6. Evalueringens fokus vil være på at afdække, hvilken af de to modeller som bedst kan afspejle virkeligheden, som den ser ud i dag og i fremtiden, hvor den overordnede målsætning må være at kunne varetage rettighedstildeling samt vedligeholdelse så nemt og bekvemt som muligt. Da der i beskrivelsen af modellerne er taget udgangspunkt i de teoretiske modeller og ikke en egentlig implementering, vil evalueringen tilsvarende være teoretisk baseret. Evalueringen vil tage udgangspunkt i de tre kategorier, som blev beskrevet i afsnit Kildekritik Da den anvendte litteratur danner grundlaget for den evaluering, som foretages i dette projekt, er det relevant at stille spørgsmålstegn ved de benyttede kilder. 4

17 Det fremgår af litteraturlisten bagerst i rapporten, at det i høj grad er de samme personer, som har skrevet litteraturen inden for et emne som RBAC. Specielt er forfattere som Sandhu, Kuhn og Ferraiolo repræsenteret i næsten alt skrevet inden for emnet. Samtidig henviser den øvrige litteratur på området til disse personers arbejde, og alle tre har været medvirkende til udarbejdelsen af de artikler [10], [27], som man ifølge National Institute of Standards and Technology (NIST) hjemmeside ( i 2004 anerkendte som en ANSI/INCITSstandard på området. Baseret på dette bør man kunne stole på kvaliteten af disse personers arbejde. Ved beskrivelsen af ABAC er situationen lidt en anden, da der egentlig ikke er skrevet særlig meget brugbart om emnet, hvilket kan skyldes, at ABAC-begrebet fortsat er forholdsvis nyt. Jeg har valgt at basere min beskrivelse på artiklen af Yuan og Tong [33], der foreslår anvendelsen af attributter som et alternativ til de rollebaserede løsninger, da denne ligger vægt på at gennemgå tankegangen bag ABAC-modellen, og den samtidig er skrevet af de forfattere, der har ytret sig mest om emnet. Som tidligere nævnt er ABAC-begrebet forholdsvist nyt, hvilket betyder, at litteraturen fokuserer på tankegangen frem for en egentlig beskrivelse af specifik funktionalitet, hvilket dog er en meget normal tilgang, som også blev brugt, da RBAC-begrebet opstod. Dengang gik der flere år, før en formel implementering fandt sted. Det betyder imidlertid, at jeg i nogle situationer har været nødsaget til at gøre nogle antagelser om, hvordan ABAC håndterer en given situation. I forbindelse med evalueringen af modellerne har jeg forsøgt at være ekstra opmærksom på at stille spørgsmålstegn ved litteraturens argumentation, da litteraturen bærer tydeligt præg af, at forfatterne er tilhængere af enten RBAC eller ABAC og derfor nok er en smule farvede i deres vurdering. 5

18 Kapitel 2 Sikkerhed i IT-systemer For at drive en sund og rentabel forretning er virksomhedernes ledelse tvunget til at tage stilling til sikkerheden på deres it-systemer. It-systemerne er som det blev beskrevet indledningsvis i denne rapport, det centrale element i virksomheden, der binder de forskellige aktiviteter sammen. Der er altså opstået et behov for at beskytte virksomhedernes computerrelaterede aktiver i form af forretningsdata, it-systemer og lignende. Virksomhederne er - for at kunne beskytte deres aktiver - nødsaget til at have en grundlæggende forståelse for de risici, der er forbundet med anvendelsen af it-systemer til håndtering af forretningsdata. På grundlag af disse risici kan virksomhederne opstille de nødvendige kontroller samt foretage modforanstaltninger, så deres it-systemer er bedst muligt beskyttet mod de forestående trusler [2], [3], [13], [15], [24]. Adressering af it-sikkerhedsproblematikken tilgås typisk ud fra det, der på engelsk er bedst kendt som CIA-princippet [24 - afsnit 1.3] eller i nogle tilfælde AIC-princippet [13 - afsnit 3], som beskriver tre vigtige aspekter i forbindelse med computerrelaterede systemer. Fortrolighed Sikkerhed Integritet Tilgængelighed Figur 2.1 Forholdet mellem fortrolighed, integritet og tilgængelighed [24]. Figur 2.1 viser forholdet mellem de tre vigtige aspekter i forbindelse med sikring af itsystemer: fortrolighed, integritet samt tilgængelighed 4, hvor en af udfordringerne ved at bygge et sikkert system er at finde den korrekte balance mellem disse. 4 På engelsk: Confidentiality, integrity og availability 6

19 Der er mange aspekter i at finde denne balance, da de tre begreber gør sig gældende for såvel systemerne som de underliggende data. Formålet med at finde balancen er at få sikret sine data samt systemer bedst muligt. 2.1 Rettighedsstyring Et af de emner, virksomhederne skal tage stilling til i forbindelse med sikring af deres it-systemer, er håndteringen af, hvem der skal have adgang til de forskellige informationer på systemerne. Dette er helt elementært for at kunne opfylde CIA-princippet og samtidig emnet for dette projekt. Man kan ikke stole på fortroligheden samt integriteten af data, hvis man ikke har styr på, hvem data er tilgængelige for, da det i princippet kan betyde, at alle har adgang til data samt lov til at manipulere med data. Hele problematikken omkring styringen af rettigheder på it-systemerne handler altså om at gøre det muligt at skelne mellem, hvem der skal have adgang til hvad, da man herved kan sikre fortroligheden såvel som integriteten af data. Derfor er der også nogle lovgivningsmæssige aspekter forbundet med rettighedsstyring. Da regnskaber og lignende også er placeret på it-systemerne, er rettighedsstyringen en nødvendighed, for at virksomhedernes revisorer kan stole på regnskabsdata [3], [11], [15]. Basalt set kan man sige, at det, man ønsker at håndtere ved hjælp af rettighedsstyring, er at kunne kontrollere brugernes færden på systemerne, hvilket typisk håndteres ved hjælp af adgangskontrol Adgangskontrol For at kunne beskrive adgangskontrolmodellerne RBAC og ABAC indgående er det vigtigt at forstå det grundlæggende behov for adgangskontrol. Formålet med adgangskontrol er at beskytte noget, der er værdifuld for dig. Det kan være smykker i en bankboks eller som i dette tilfælde data på en virksomheds it-systemer, som man ikke ønsker at andre skal få fingre i. Adgangskontrol er samtidig som beskrevet et vidt begreb, som dækker over mange forskellige måder at foretage adgangskontrol på. Det kan være en fysisk adgangskontrol i form af nøgler til en dør, tremmer for vinduerne eller lignende, men der kan også være tale om systemmæssig adgang til en ressource på et it-system, hvilket er den type adgangskontrol, som beskrives i dette projekt [12], [13 - afsnit 4], [24]. 7

20 Figur 2.2 Adgangskontrolforløb [13 - figur 4.2]. Som figur 2.2 viser, er der tre skridt, som skal udføres, for at en bruger får adgang til den ønskede ressource. Ydermere illustrerer figuren, at man ønsker at kunne holde brugeren ansvarlig for de operationer, han/hun har udført på systemet, hvilket dog ikke er så relevant i denne sammenhæng, men vil blive beskrevet nærmere i afsnit For at bestemme en brugers adgang til en ressource skal der altså udføres tre ting: 1. Brugeren skal identificeres, hvilket typisk gøres ved brugeren selv oplyser et brugernavn, CPR-nr. eller lignende. 2. Identifikationsinformationerne verificeres for at sikre, at brugeren rent faktisk er den, han/hun udgiver sig for at være, hvilket typisk udføres ved, at brugeren har noget viden i form af f.eks. et kodeord, som kombineret med brugernavnet danner grundlag for verificeringen. 3. Virksomhedens it-sikkerhedspolitik indeholder informationer om hvem der må hvad på systemerne, derfor er skridt 1 og 2 nødvendige for at finde ud af hvem den pågældende bruger og herefter ud fra politikken afgøre, hvilke operationer denne bruger har lov at udføre. Man kan altså sige, at der foretages adgangskontrol ved grænsen til applikationen i form af step 1-2, hvor det afgøres, om brugeren i det hele taget skal have adgang til applikationen. Ydermere foretages der efterfølgende adgangskontrol i form af step 3, som afgør, hvilke data samt operationer den pågældende bruger har lov til at udføre i applikationen [13 - afsnit 4]. Det betyder, at der for hver enkelt ressource på et it-system skal tages stilling til, hvem der må få adgang, samt hvad de må udføre Klassiske adgangskontrolmodeller At der foretages adgangskontrol er et skridt på vejen, men det helt elementære i forbindelse med rettighedsstyring er, at rettighederne tildeles ud fra nogle faste koncepter, da sikkerheden på et it-system aldrig er stærkere end det svageste led [28]. 8

21 Indførelsen af en adgangskontrolmodel til håndhævelse af, hvordan rettigheder tildeles, er derfor helt centralt for at højne datasikkerheden. Overordnet kan modeller til tildeling af rettigheder på it-systemer, inddeles i to kategorier: discretionary-adgangskontrol 5 (DAC) samt mandatory-adgangskontrol 6 (MAC) [13 - afsnit 4], [24 - afsnit 5]. Discretionary Access Control Grundprincippet i DAC er, at det er ejeren af en ressource, der afgør, hvem der skal have adgang til ressourcen. Ejerskab af en ressource tildeles som udgangspunkt til den person, som opretter ressourcen. Men ejerskab kan også tildeles en navngiven person, hvilket f.eks. kunne være en afdelingsleder, manager eller lignende, som tildeles ejerskab til filer og ressourcer inden for en afdeling. Der er altså tale om en dynamisk adgangskontrolmodel, hvor der decentralt kan tages stilling til, hvem der skal have adgang til hvad. Den mest almindelige implementering af DAC er ved hjælp af adgangskontrollister 7 (ACL), hvor der for hver ressource er en liste, som specificerer, hvilke brugere der har adgang til denne ressource. Problematikken ved anvendelsen af DAC er, at virksomhederne ikke har mulighed for at håndhæve et grundlæggende sikkerhedsniveau, idet de enkelte ressourceejere kan tildele rettigheder til deres ressourcer. Derfor kan sikkerhedsniveauet variere meget på tværs af en organisation [13 - afsnit 4], [24 - afsnit 5]. Mandatory Access Control MAC er i princippet modsætningen til DAC, da der foretages en centraliseret styring af rettighederne, hvor systemadministrationen opstiller en generel adgangspolitik, som ikke kan tilsidesættes af den enkelte ressourceejer. Der er altså tale om en langt mere struktureret samt streng adgangskontrol, hvor der centralt tages stilling til, hvem der skal have adgang til hvad. Problematikken ved anvendelse af MAC er, at den er meget firkantet og svær at tilpasse til de eksakte behov i en virksomhed. MAC kan dog i modsætning til DAC sikre et ensartet sikkerhedsniveau hele vejen på tværs af en organisation [13 - afsnit 4], [24 - afsnit 5]. Opsummering Fællesnævner for de klassiske adgangskontrolmodeller har imidlertid intet at gøre med, hvem der står for tildelingen af rettigheder, men er, at både MAC og DAC tildeler rettigheder individuelt til brugerne, hvilket kan blive uhåndterligt på et system med mange brugere. De nye adgangskontrolmodeller RBAC og ABAC er faktisk ikke så forskellige fra MAC og DAC, da de fortsat arbejder ud fra en kombination af principperne bag MAC 5 På engelsk: Discretionary Access Control 6 På engelsk: Mandatory Access Control 7 På engelsk: Access Control List 9