{"id":87793,"date":"2020-07-10T13:41:57","date_gmt":"2020-07-10T11:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya"},"modified":"2020-07-10T13:41:57","modified_gmt":"2020-07-10T11:41:57","slug":"stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","title":{"rendered":"Vi bygger en rollemodel for adgangsstyring. Del et, forberedende","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I currently work for a software vendor, specifically in access management solutions. My experience 'from a past life' is connected to the client side \u2013 a large financial organization. Back then, our access control group in the information security department couldn't boast significant competencies in IdM. We learned a lot in the process, and it took a lot of bumps to build a functioning user rights management mechanism in the company's information systems.
\n\"Vi
\nBy combining my hard-earned experience from the client side with vendor knowledge and competencies, I want to share with you essentially a step-by-step guide: how to create a role-based access management model in a large company, and what it will yield. My guide consists of two parts: the first \u2013 preparing to build the model, the second \u2013 actually building it. Here is part one, the preparatory phase.
\n<\/a><\/noindex>
\nN.B.<\/b> Building a role model is, unfortunately, not an end result but a process. More precisely, it is even part of the process of creating an access management ecosystem within the company. So, get ready for a long-term endeavor.
\n<\/i>
\nFirst, let\u2019s define what role-based access management is. Imagine you have a large bank with tens or even hundreds of thousands of employees (subjects), each of whom has dozens of access rights to hundreds of internal banking information systems (objects). Now multiply the number of objects by the number of subjects \u2013 that\u2019s the minimum number of connections you need to build and then control. Is it really feasible to do this manually? Of course not \u2013 that\u2019s why roles were introduced.<\/p>\n

A role is a set of permissions necessary for a user or group of users to perform specific work tasks. Each employee may have one or more roles, and each role can contain from one to many permissions granted to the user within that role. Roles can be tied to specific positions, departments, or functional tasks of the employees.<\/p>\n

\"Vi
\n
\nRoller oprettes normalt ud fra de enkelte medarbejderes bef\u00f8jelser i hvert informationssystem. Derefter dannes de globale forretningsroller ud fra rollerne i hvert system. For eksempel vil forretningsrollen \"kreditmanager\" inkludere flere separate roller i de informationssystemer, der anvendes i bankens kundeafdeling. Lad os sige, i systemer som den prim\u00e6re automatiserede banksystem, kassemodulet, systemet til elektronisk dokumenth\u00e5ndtering, service manager og andre. Forretningsroller knyttes som regel til den organisatoriske struktur - kort sagt, til et s\u00e6t af virksomhedens afdelinger og stillinger. S\u00e5ledes dannes en global rollmatrix (et eksempel, som jeg giver i tabellen nedenfor).<\/p>\n

\"Vi
\n
\nDet er v\u00e6rd at bem\u00e6rke, at det er umuligt at bygge en 100% rollemodel, der giver alle n\u00f8dvendige rettigheder til medarbejderne i hver stilling i en kommerciel struktur. Og det er heller ikke n\u00f8dvendigt. For rollemodellen kan ikke v\u00e6re statisk, da den afh\u00e6nger af det konstant skiftende milj\u00f8. Og af \u00e6ndringen i virksomhedens forretningsaktiviteter, hvilket p\u00e5virker \u00e6ndringen i organisationsstrukturen og funktionaliteten. Og af manglen p\u00e5 fuld ressourceforsyning, og af manglende overholdelse af arbejdsinstrukser, og af str\u00e6ben efter profit p\u00e5 bekostning af sikkerhed, og af mange andre faktorer. Derfor skal man bygge en rollemodel, der kan d\u00e6kke op til 80% af brugernes behov for n\u00f8dvendige grundl\u00e6ggende rettigheder ved ans\u00e6ttelse. De resterende 20% kan de, hvis n\u00f8dvendigt, anmode om senere via separate anmodninger.<\/p>\n

Selvf\u00f8lgelig kan du sp\u00f8rge: \"Er der slet ikke 100% rollemodeller?\" Jamen, hvorfor ikke, s\u00e5dan noget findes, for eksempel i nonprofitorganisationer, der ikke uds\u00e6ttes for hyppige \u00e6ndringer - i en hvilken som helst forskningsinstitution. Eller i virksomheder inden for forsvarsindustrien med et h\u00f8jt niveau af sikkerhed, hvor sikkerhed er \u00f8verst p\u00e5 dagsordenen. Det forekommer ogs\u00e5 i kommercielle strukturer, men inden for en enkelt afdeling, hvis arbejde er en forholdsvis statisk og forudsigelig proces.<\/p>\n

Den st\u00f8rste fordel ved rolleadministration er, at det forenkler tildelingen af rettigheder, fordi antallet af roller er betydeligt mindre end antallet af brugere af informationssystemet. Dette g\u00e6lder for enhver branche.<\/p>\n

Lad os tage en detailvirksomhed: den har tusindvis af s\u00e6lgere, men de har alle de samme rettigheder i system N, og der vil kun blive oprettet \u00e9n rolle for dem. N\u00e5r en ny s\u00e6lger kommer til virksomheden, tildeles han automatisk den n\u00f8dvendige rolle i systemet, som allerede har alle de n\u00f8dvendige bef\u00f8jelser. P\u00e5 samme m\u00e5de kan man med et klik \u00e6ndre rettighederne for tusindvis af s\u00e6lgere p\u00e5 \u00e9n gang, for eksempel tilf\u00f8je en ny mulighed for at generere rapporter. Man beh\u00f8ver ikke at foretage tusinde operationer for at knytte den nye ret til hver enkelt konto \u2013 det er nok at tilf\u00f8je denne mulighed til rollen, s\u00e5 den vises for alle s\u00e6lgere samtidig.<\/p>\n

En anden fordel ved rollebaseret administration er udelukkelsen af tildeling af inkompatible bef\u00f8jelser. Det vil sige, at en medarbejder, der har en bestemt rolle i systemet, ikke kan have en anden rolle, hvis rettighederne ikke skal kombineres med rettighederne i den f\u00f8rste. Et tydeligt eksempel er forbuddet mod at kombinere funktioner til indtastning og kontrol af finansielle operationer.<\/p>\n

Alle, der er interesserede i, hvordan rollebaseret adgangsstyring overhovedet opstod, kan
\n dykke ned i et historisk perspektiv.<\/b>
\n Hvis vi ser tilbage i historien, s\u00e5 t\u00e6nkte IT-samfundet f\u00f8rste gang over metoder til adgangsstyring allerede i 1970'erne. Selvom applikationerne dengang var ret simple, havde man ligesom nu et st\u00e6rkt \u00f8nske om at kunne styre adgangen til dem p\u00e5 en bekvem m\u00e5de. At give, \u00e6ndre og kontrollere brugernes rettigheder \u2013 blot for at det blev lettere at forst\u00e5, hvilken adgang hver enkelt bruger havde. Men dengang fandtes der ingen f\u00e6lles standarder, de f\u00f8rste adgangsstyringssystemer blev udviklet, og hver virksomhed baserede sig p\u00e5 sine egne forestillinger og regler.<\/p>\n

I dag kender vi mange forskellige modeller for adgangsstyring, men de dukkede ikke op med det samme. Lad os fokusere p\u00e5 dem, der har gjort en betydelig indsats for udviklingen af dette omr\u00e5de.<\/p>\n

Den f\u00f8rste og m\u00e5ske den simpleste model \u2013 Diskretion\u00e6r (v\u00e6lgelsesbaseret) adgangsstyring.<\/b> (DAC \u2013 Discretionary access control). Denne model indeb\u00e6rer, at alle deltagere i adgangsprocessen deler rettighederne. Hver bruger f\u00e5r adgang til specifikke objekter eller operationer. I bund og grund svarer m\u00e6ngden af rettighedssubjekter til m\u00e6ngden af objekter. Denne model blev anerkendt som for fleksibel og for kompleks at vedligeholde: adgangslisterne bliver over tid enorme og sv\u00e6re at kontrollere.<\/p>\n

Den anden model er Mandatkontrol (MAC \u2014 Mandatory access control)<\/b>. I denne model f\u00e5r hver bruger adgang til et objekt i henhold til en udstedt tilladelse til et bestemt niveau af datafortrolighed. F\u00f8lgelig skal objekterne kategoriseres efter niveauet af fortrolighed. I mods\u00e6tning til den f\u00f8rste fleksible model, er denne derimod alt for striks og begr\u00e6nsende. Dens anvendelse retf\u00e6rdigg\u00f8r ikke sig selv, n\u00e5r der i virksomheden er mange forskellige informationsressourcer: for at begr\u00e6nse adgangen til forskellige ressourcer, skal der indf\u00f8res mange kategorier, som ikke vil krydse hinanden.<\/p>\n

I forbindelse med de \u00e5benlyse mangler ved disse to metoder fortsatte IT-samfundet udviklingen af modeller, der er mere fleksible og mere eller mindre universelle til at st\u00f8tte forskellige typer organisatoriske politikker for adgangskontrol. Og s\u00e5 opstod den tredje model for adgangsstyring baseret p\u00e5 roller!<\/b> Denne tilgang har vist sig at v\u00e6re den mest lovende, da den kr\u00e6ver ikke blot godkendelse af brugerens identitet, men ogs\u00e5 hans arbejdsm\u00e6ssige funktioner i systemerne.<\/p>\n

Den f\u00f8rste klart beskrevede struktur for den rollebaserede model blev foresl\u00e5et af de amerikanske forskere David Ferraiolo og Richard Kuhn fra National Institute of Standards and Technology i USA i 1992. Her blev termen for f\u00f8rste gang introduceret: RBAC (Role-based access control). <\/b>Disse unders\u00f8gelser og beskrivelser af de grundl\u00e6ggende komponenter samt deres indbyrdes relationer lagde grunden til den g\u00e6ldende standard INCITS 359-2012, godkendt af den Internationale Komit\u00e9 for Standarder inden for Informationsteknologi (INCITS).<\/p>\n

Standarden definerer rollen som \"en arbejdsfunktion i konteksten af organisationen med en vis tilknyttet semantik vedr\u00f8rende de bef\u00f8jelser og ansvar, der p\u00e5l\u00e6gges brugeren, der er tildelt rollen.\" Dokumentet fastl\u00e6gger de grundl\u00e6ggende elementer i RBAC \u2013 brugere, sessioner, roller, tilladelser, operationer og objekter, samt forholdene og relationerne mellem dem.<\/p>\n

Standarden indeholder den minimum n\u00f8dvendige struktur til opbygning af en rollemodel \u2013 samling af rettigheder i roller og derefter tildeling af adgang til brugerne gennem disse roller. Der er angivet mekanismer til at sammens\u00e6tte roller ud fra objekter og operationer, og der beskrives hierarkiet i roller og arv af bef\u00f8jelser. For enhver virksomhed findes der roller, der samler grundl\u00e6ggende bef\u00f8jelser, som er n\u00f8dvendige for alle medarbejdere i virksomheden. Dette kan v\u00e6re adgang til e-mail, til ESDH, til det interne portal osv. Disse bef\u00f8jelser kan inkluderes i en overordnet rolle kaldet \"medarbejder\", s\u00e5 der ikke skal listes alle de grundl\u00e6ggende rettigheder gentagne gange i hver af de h\u00f8jere roller. Det er tilstr\u00e6kkeligt blot at angive arvet karakter af rollen \"medarbejder.\"<\/p>\n

\"Vi
\n
\nSenere blev standarden udvidet med nye adgangs-attributter relateret til det konstant foranderlige milj\u00f8. Muligheden for at indf\u00f8re statiske og dynamiske begr\u00e6nsninger blev tilf\u00f8jet. Statiske henviser til umuligheden af at kombinere roller (den n\u00e6vnte indf\u00f8rsel og kontrol af operationer ovenfor). Dynamiske begr\u00e6nsninger kan bestemmes af skiftende parametre, s\u00e5som tid (arbejde\/ikke-arbejde timer eller dage), placering (kontor\/hjem) osv.<\/p>\n

Det er v\u00e6rd at n\u00e6vne adgangsstyring baseret p\u00e5 attributter (ABAC \u2014 Attribute-based access control).<\/b> Tilgangen er baseret p\u00e5 at give adgang gennem regler for deling af attributter. Denne model kan anvendes separat, men bruges ofte aktivt som supplement til den klassiske rollemodel: til en bestemt rolle kan der tilf\u00f8jes attributter fra brugere, ressourcer og enheder samt tid eller placering. Dette g\u00f8r det muligt at anvende f\u00e6rre roller, indf\u00f8je yderligere begr\u00e6nsninger og g\u00f8re adgangen minimal tilstr\u00e6kkelig, hvilket dermed \u00f8ger sikkerheden.<\/p>\n

For example, an accountant can be granted access to accounts if they work in a specific region. The specialist's location will then be compared to a certain benchmark value. Alternatively, access to accounts can be granted only if the user logs in from a registered authorized device. This is a good addition to the role model but is not often used independently due to the need to create many rules and permission or restriction tables.<\/p>\n

Let me give you an example of ABAC from my 'previous life.' In our bank, there were several branches. Employees at the client offices in these branches performed absolutely identical operations but were only allowed to work in the main system with accounts from their region. Initially, we started creating separate roles for each region \u2013 and there ended up being a very large number of such roles with repeating functions but access to different accounts! Then, by using the user's location attribute and linking it to a specific range of accounts for verification, we significantly reduced the number of roles in the system. As a result, only roles for one branch remained, which were replicated across the corresponding positions in all other territorial divisions of the bank.<\/p>\n

Now, let's talk about the necessary preparatory steps without which it is simply impossible to build a working role model.<\/p>\n

Step 1. We create a functional model.<\/h2>\n

\nDet er vigtigt at starte med at skabe en funktionel model \u2013 et overordnet dokument, der detaljeret beskriver funktionerne for hver afdeling og hver stilling. Oplysningerne stammer som regel fra forskellige dokumenter: stillingsbeskrivelser og vedt\u00e6gter for de enkelte afdelinger \u2013 kontorer, ledelser, afdelinger. Den funktionelle model skal godkendes af alle interessenter (forretning, intern kontrol, sikkerhed) og bekr\u00e6ftes af ledelsen. Hvad er form\u00e5let med dette dokument? S\u00e5 den rollebaserede model kan henvise til det. For eksempel, hvis du planl\u00e6gger at bygge en rollemodel baseret p\u00e5 de eksisterende rettigheder for medarbejdere \u2013 udvundet fra systemet og \"bragt til f\u00e6lles standard\". S\u00e5 kan man ved godkendelsen af de modtagne roller fra systemets forretningsansvarlige henvise til det specifikke punkt i den funktionelle model, der ligger til grund for, at en given rettighed inkluderes i rollen.<\/p>\n

Trin 2. Gennemf\u00f8r en revision af IT-systemer og udarbejd en prioriteringsplan<\/h2>\n

\nI det andet trin b\u00f8r der gennemf\u00f8res en revision af IT-systemer for at forst\u00e5, hvordan adgangen til dem er organiseret. For eksempel, i mit finansielle selskab blev der anvendt flere hundrede informationssystemer. Alle systemer havde nogle elementer af rollebaseret styring, i de fleste var der nogle roller, men hovedsageligt p\u00e5 papir eller i systemets bibliotek \u2013 de var l\u00e6nge siden for\u00e6ldede, og adgangen blev givet baseret p\u00e5 faktiske foresp\u00f8rgsler fra brugerne. Det er naturligvis umuligt at bygge en rollemodel med det samme i flere hundrede systemer; man m\u00e5 starte et sted. Vi udf\u00f8rte en dybdeg\u00e5ende analyse af adgangsstyringsprocessen for at bestemme niveauet for dets modenhed. I analysen udviklede vi kriterier for prioritering af informationssystemer \u2013 kritikalitet, klarhed, planer om udfasning mv. Ved hj\u00e6lp af disse kriterier skabte vi r\u00e6kkef\u00f8lgen for udviklingen\/opdateringen af rollemodeller for disse systemer. Og derefter \u2013 indarbejdede vi rollemodellerne i integrationsplanen med Identity Management-l\u00f8sningen for at automatisere adgangsstyringen.<\/p>\n

S\u00e5 hvordan definerer man kritikalitet af et system? Besvar f\u00f8lgende sp\u00f8rgsm\u00e5l:<\/p>\n