I currently work for a software vendor, specifically in access management solutions. My experience 'from a past life' is connected to the client side – 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.
By 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 – preparing to build the model, the second – actually building it. Here is part one, the preparatory phase.
N.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.
First, let’s 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 – that’s the minimum number of connections you need to build and then control. Is it really feasible to do this manually? Of course not – that’s why roles were introduced.
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.
Roller oprettes normalt ud fra de enkelte medarbejderes beføjelser 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ære automatiserede banksystem, kassemodulet, systemet til elektronisk dokumenthåndtering, service manager og andre. Forretningsroller knyttes som regel til den organisatoriske struktur - kort sagt, til et sæt af virksomhedens afdelinger og stillinger. Således dannes en global rollmatrix (et eksempel, som jeg giver i tabellen nedenfor).
Det er værd at bemærke, at det er umuligt at bygge en 100% rollemodel, der giver alle nødvendige rettigheder til medarbejderne i hver stilling i en kommerciel struktur. Og det er heller ikke nødvendigt. For rollemodellen kan ikke være statisk, da den afhænger af det konstant skiftende miljø. Og af ændringen i virksomhedens forretningsaktiviteter, hvilket påvirker ændringen i organisationsstrukturen og funktionaliteten. Og af manglen på fuld ressourceforsyning, og af manglende overholdelse af arbejdsinstrukser, og af stræben efter profit på bekostning af sikkerhed, og af mange andre faktorer. Derfor skal man bygge en rollemodel, der kan dække op til 80% af brugernes behov for nødvendige grundlæggende rettigheder ved ansættelse. De resterende 20% kan de, hvis nødvendigt, anmode om senere via separate anmodninger.
Selvfølgelig kan du spørge: "Er der slet ikke 100% rollemodeller?" Jamen, hvorfor ikke, sådan noget findes, for eksempel i nonprofitorganisationer, der ikke udsættes for hyppige ændringer - i en hvilken som helst forskningsinstitution. Eller i virksomheder inden for forsvarsindustrien med et højt niveau af sikkerhed, hvor sikkerhed er øverst på dagsordenen. Det forekommer også i kommercielle strukturer, men inden for en enkelt afdeling, hvis arbejde er en forholdsvis statisk og forudsigelig proces.
Den største 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ælder for enhver branche.
Lad os tage en detailvirksomhed: den har tusindvis af sælgere, men de har alle de samme rettigheder i system N, og der vil kun blive oprettet én rolle for dem. Når en ny sælger kommer til virksomheden, tildeles han automatisk den nødvendige rolle i systemet, som allerede har alle de nødvendige beføjelser. På samme måde kan man med et klik ændre rettighederne for tusindvis af sælgere på én gang, for eksempel tilføje en ny mulighed for at generere rapporter. Man behøver ikke at foretage tusinde operationer for at knytte den nye ret til hver enkelt konto – det er nok at tilføje denne mulighed til rollen, så den vises for alle sælgere samtidig.
En anden fordel ved rollebaseret administration er udelukkelsen af tildeling af inkompatible beføjelser. 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ørste. Et tydeligt eksempel er forbuddet mod at kombinere funktioner til indtastning og kontrol af finansielle operationer.
Alle, der er interesserede i, hvordan rollebaseret adgangsstyring overhovedet opstod, kan
dykke ned i et historisk perspektiv.
Hvis vi ser tilbage i historien, så tænkte IT-samfundet første gang over metoder til adgangsstyring allerede i 1970'erne. Selvom applikationerne dengang var ret simple, havde man ligesom nu et stærkt ønske om at kunne styre adgangen til dem på en bekvem måde. At give, ændre og kontrollere brugernes rettigheder – blot for at det blev lettere at forstå, hvilken adgang hver enkelt bruger havde. Men dengang fandtes der ingen fælles standarder, de første adgangsstyringssystemer blev udviklet, og hver virksomhed baserede sig på sine egne forestillinger og regler.
I dag kender vi mange forskellige modeller for adgangsstyring, men de dukkede ikke op med det samme. Lad os fokusere på dem, der har gjort en betydelig indsats for udviklingen af dette område.
Den første og måske den simpleste model – Diskretionær (vælgelsesbaseret) adgangsstyring. (DAC – Discretionary access control). Denne model indebærer, at alle deltagere i adgangsprocessen deler rettighederne. Hver bruger får adgang til specifikke objekter eller operationer. I bund og grund svarer mængden af rettighedssubjekter til mængden af objekter. Denne model blev anerkendt som for fleksibel og for kompleks at vedligeholde: adgangslisterne bliver over tid enorme og svære at kontrollere.
Den anden model er Mandatkontrol (MAC — Mandatory access control). I denne model får hver bruger adgang til et objekt i henhold til en udstedt tilladelse til et bestemt niveau af datafortrolighed. Følgelig skal objekterne kategoriseres efter niveauet af fortrolighed. I modsætning til den første fleksible model, er denne derimod alt for striks og begrænsende. Dens anvendelse retfærdiggør ikke sig selv, når der i virksomheden er mange forskellige informationsressourcer: for at begrænse adgangen til forskellige ressourcer, skal der indføres mange kategorier, som ikke vil krydse hinanden.
I forbindelse med de åbenlyse mangler ved disse to metoder fortsatte IT-samfundet udviklingen af modeller, der er mere fleksible og mere eller mindre universelle til at støtte forskellige typer organisatoriske politikker for adgangskontrol. Og så opstod den tredje model for adgangsstyring baseret på roller! Denne tilgang har vist sig at være den mest lovende, da den kræver ikke blot godkendelse af brugerens identitet, men også hans arbejdsmæssige funktioner i systemerne.
Den første klart beskrevede struktur for den rollebaserede model blev foreslået 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ørste gang introduceret: RBAC (Role-based access control). Disse undersøgelser og beskrivelser af de grundlæggende komponenter samt deres indbyrdes relationer lagde grunden til den gældende standard INCITS 359-2012, godkendt af den Internationale Komité for Standarder inden for Informationsteknologi (INCITS).
Standarden definerer rollen som "en arbejdsfunktion i konteksten af organisationen med en vis tilknyttet semantik vedrørende de beføjelser og ansvar, der pålægges brugeren, der er tildelt rollen." Dokumentet fastlægger de grundlæggende elementer i RBAC – brugere, sessioner, roller, tilladelser, operationer og objekter, samt forholdene og relationerne mellem dem.
Standarden indeholder den minimum nødvendige struktur til opbygning af en rollemodel – samling af rettigheder i roller og derefter tildeling af adgang til brugerne gennem disse roller. Der er angivet mekanismer til at sammensætte roller ud fra objekter og operationer, og der beskrives hierarkiet i roller og arv af beføjelser. For enhver virksomhed findes der roller, der samler grundlæggende beføjelser, som er nødvendige for alle medarbejdere i virksomheden. Dette kan være adgang til e-mail, til ESDH, til det interne portal osv. Disse beføjelser kan inkluderes i en overordnet rolle kaldet "medarbejder", så der ikke skal listes alle de grundlæggende rettigheder gentagne gange i hver af de højere roller. Det er tilstrækkeligt blot at angive arvet karakter af rollen "medarbejder."
Senere blev standarden udvidet med nye adgangs-attributter relateret til det konstant foranderlige miljø. Muligheden for at indføre statiske og dynamiske begrænsninger blev tilføjet. Statiske henviser til umuligheden af at kombinere roller (den nævnte indførsel og kontrol af operationer ovenfor). Dynamiske begrænsninger kan bestemmes af skiftende parametre, såsom tid (arbejde/ikke-arbejde timer eller dage), placering (kontor/hjem) osv.
Det er værd at nævne adgangsstyring baseret på attributter (ABAC — Attribute-based access control). Tilgangen er baseret på 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øjes attributter fra brugere, ressourcer og enheder samt tid eller placering. Dette gør det muligt at anvende færre roller, indføje yderligere begrænsninger og gøre adgangen minimal tilstrækkelig, hvilket dermed øger sikkerheden.
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.
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 – 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.
Now, let's talk about the necessary preparatory steps without which it is simply impossible to build a working role model.
Step 1. We create a functional model.
Det er vigtigt at starte med at skabe en funktionel model – et overordnet dokument, der detaljeret beskriver funktionerne for hver afdeling og hver stilling. Oplysningerne stammer som regel fra forskellige dokumenter: stillingsbeskrivelser og vedtægter for de enkelte afdelinger – kontorer, ledelser, afdelinger. Den funktionelle model skal godkendes af alle interessenter (forretning, intern kontrol, sikkerhed) og bekræftes af ledelsen. Hvad er formålet med dette dokument? Så den rollebaserede model kan henvise til det. For eksempel, hvis du planlægger at bygge en rollemodel baseret på de eksisterende rettigheder for medarbejdere – udvundet fra systemet og "bragt til fælles standard". Så 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.
Trin 2. Gennemfør en revision af IT-systemer og udarbejd en prioriteringsplan
I det andet trin bør der gennemføres en revision af IT-systemer for at forstå, 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å papir eller i systemets bibliotek – de var længe siden forældede, og adgangen blev givet baseret på faktiske forespørgsler fra brugerne. Det er naturligvis umuligt at bygge en rollemodel med det samme i flere hundrede systemer; man må starte et sted. Vi udførte en dybdegående analyse af adgangsstyringsprocessen for at bestemme niveauet for dets modenhed. I analysen udviklede vi kriterier for prioritering af informationssystemer – kritikalitet, klarhed, planer om udfasning mv. Ved hjælp af disse kriterier skabte vi rækkefølgen for udviklingen/opdateringen af rollemodeller for disse systemer. Og derefter – indarbejdede vi rollemodellerne i integrationsplanen med Identity Management-løsningen for at automatisere adgangsstyringen.
Så hvordan definerer man kritikalitet af et system? Besvar følgende spørgsmål:
- Er systemet relateret til de operationelle processer, hvis udførelse afhænger af virksomhedens kerneaktiviteter?
- Vil forstyrrelsen af systemets funktion påvirke integriteten af virksomhedens aktiver?
- Hvad er den maksimalt acceptable nedetid for systemet, som, når den er nået, gør det umuligt at genoprette aktiviteten efter en afbrydelse?
- Kan et brud på informationens integritet i systemet føre til uoprettelige konsekvenser, både økonomisk og omdømmemæssigt?
- Kritikalitet over for svindel. Tilstedeværelsen af funktionalitet, hvor utilstrækkelig kontrol kan muliggøre interne/eksterne svindelhandlinger;
- Hvad er kravene fra lovgivningen samt interne regler og procedurer til disse systemer? Vil der være bøder fra regulatorer for manglende overholdelse?
I vores finansielle virksomhed har vi gennemført en revision på denne måde. Ledelsen har udviklet en procedure for Audit Access Right Review for at få overblik over eksisterende brugere og rettigheder først i de informationssystemer, der er blevet prioriteret højt. Ejeren af denne proces blev udpeget til sikkerhedsafdelingen. Men for at få det fulde billede af adgangen i virksomheden var det nødvendigt at inddrage IT- og forretningsafdelingerne i processen. Her begyndte uenigheder, misforståelser og nogle gange endda sabotage: ingen ønsker at afbryde deres nuværende opgaver og involvere sig i tilsyneladende ukendte aktiviteter.
N.B. Store virksomheder med udviklede IT-processer kender helt sikkert til proceduren for IT-revision – IT general controls (ITGC), som gør det muligt at identificere mangler i IT-processerne og etablere kontrol, så processerne kan forbedres i overensstemmelse med best practice (ITIL, COBIT, IT Governance osv.). En sådan revision gør det muligt for IT og forretningen at forstå hinanden bedre og udvikle en fælles udviklingsstrategi, analysere risici, optimere omkostninger og udvikle mere effektive arbejdsmetoder.
En af retningerne for revisionen er at bestemme parametre for logisk og fysisk adgang til informationssystemer. De indsamlede data brugte vi som grundlag for videre anvendelse i opbygningen af en rollemodel. Resultatet af denne revision var en registrering af IT-systemer, hvor deres tekniske parametre blev defineret og beskrevet. Derudover blev der for hvert system udpeget en ejer fra forretningsretningen, som systemet blev drevet i interessen for: det var netop ham, der var ansvarlig for de forretningsprocesser, som dette system betjente. Der blev også udnævnt en IT-tjenesteleder, som var ansvarlig for den tekniske implementering af forretningens behov i det specifikke informationssystem. De mest kritiske systemer for virksomheden og deres tekniske parametre, samt tidsplaner for opstart og nedlæggelse, blev dokumenteret. Disse parametre har været en stor hjælp i forberedelsen til opbygningen af en rollemodel.
Trin 3 Opretter vi metodologi
Nøglen til succes i enhver opgave er den rigtige metode. Derfor er det også nødvendigt at skabe en metodologi for både opbygningen af en rollemodel og gennemførelsen af revisionen, hvor vi beskriver samarbejdet mellem afdelingerne, fastsætter ansvar i virksomhedens regulativer osv.
For at begynde skal vi undersøge alle eksisterende dokumenter, der fastlægger procedurerne for adgang og rettigheder. Ideelt set bør processerne være dokumenteret på flere niveauer:
- generelle virksomhedskrav;
- krav til informationssikkerhedsområder (afhænger af organisationens aktivitetsretninger);
- krav til teknologiske processer (instruktioner, adgangsmatrixer, metodiske henvisninger, konfigurationskrav).
I vores finansielle virksomhed opdagede vi mange forældede dokumenter – vi måtte bringe dem i overensstemmelse med de nye processer, der blev implementeret.
Efter ordre fra ledelsen blev der oprettet en arbejdsgruppe, der inkluderede repræsentanter fra sikkerhed, IT, forretning og intern kontrol. I ordren blev målene for oprettelse af gruppen, aktivitetens retning, eksistensperioden og ansvarlige fra hver side angivet. Derudover har vi udviklet en metode til udførelse af revision og en procedure for opbygningen af en rollemodel: disse blev godkendt af alle ansvarlige repræsentanter og godkendt af virksomhedens ledelse.
Dokumenter, der beskriver procedurerne for udførelse af arbejdet, tidsrammerne, ansvarsområderne osv. – er nøglen til, at der på vejen mod den ønskede målsætning, som i starten ikke er åbenlys for alle, ikke opstår spørgsmål som 'hvorfor gør vi dette, hvorfor er det nødvendigt osv.' og der vil ikke være mulighed for at 'slippe væk' eller bremse processen.
Trin 4. Fastlægger parametrene for den eksisterende adgangsstyringsmodel
Vi udarbejder det såkaldte 'systempas' i forbindelse med adgangsstyring. I bund og grund er det et spørgeskema for det specifikke informationssystem, der dokumenterer alle algoritmer til adgangsstyring til det. Virksomheder, der tidligere har implementeret IdM-løsninger, vil være fortrolige med et sådant spørgeskema, da det ofte er, hvorundersøgelsen af systemerne begynder.
En del af parametrene om systemet og ejerne er sendt videre til spørgeskemaet fra IT-registret (se trin 2, revision), men der er også tilføjet nye:
- hvordan håndteres kontoadministration (direkte i databasen eller via programmeringsgrænseflader);
- hvordan brugerne logger ind på systemet (ved hjælp af en separat konto eller ved brug af AD, LDAP osv.);
- hvilke adgangsniveauer der bruges til systemet (applikationsniveau, systemniveau, brug af nettets filressourcer);
- beskrivelse og parametre servere, som systemet fungerer på;
- hvilke operationer til kontoadministration der understøttes (blokering, omdøbning osv.);
- hvilke algoritmer eller regler der bruges til at danne systemets bruger-ID;
- hvilket attribut der kan knyttes til medarbejderens post i personalsystemet (navn, medarbejdernummer eller andet);
- alle mulige attributter for kontoen og reglerne for deres udfyldelse;
- hvilke adgangsrettigheder der findes i systemet (roller, grupper, atomare rettigheder osv., om der findes indlejrede eller hierarkiske rettigheder);
- adgangsdelingsmekanismer (efter stillinger, afdelinger, funktioner osv.);
- er der i systemet regler for adskillelse af opgaver (SOD – Segregation of Duties), og hvordan fungerer de;
- hvordan håndteres hændelser om fravær, overførsel, afskedigelse, opdatering af medarbejderdata osv. i systemet?
Man kan fortsætte denne liste med detaljer om forskellige parametre og andre objekter, der er involveret i adgangsstyringsprocessen.
Trin 5. Opretter en forretningsorienteret beskrivelse af beføjelser
Endnu et dokument, vi får brug for, når vi opbygger en rollemodel, er en vejledning til alle mulige beføjelser (rettigheder), der kan gives brugere i informationssystemet med en detaljeret beskrivelse af den forretningsfunktion, der ligger bag. Oftest er beføjelser i systemet kodet med bestemte betegnelser bestående af bogstaver og tal, og forretningsmedarbejdere kan ikke forstå, hvad der ligger bag disse symboler. Så går de til IT-afdelingen, men de kan også ikke svare på spørgsmål om f.eks. sjældent anvendte rettigheder. Så er det nødvendigt at udføre yderligere test.
Det er godt, hvis der allerede findes en forretningsbeskrivelse, eller hvis disse rettigheder endda er samlet i grupper og roller. For nogle applikationer er det bedst at oprette en sådan vejledning allerede under udviklingen. Men dette forekommer sjældent, så vi går igen til IT-afdelingen for at samle information om alle mulige rettigheder og beskrive dem. Vores vejledning vil i sidste ende indeholde følgende:
- navn på beføjelsen, inklusive objektet, som adgangsretten gælder for;
- handling, der er tilladt at udføre med objektet (visning, ændring osv., mulighed for begrænsning, f.eks. efter geografisk område eller kundegruppe);
- beføjelsernes kode (koden og navnet på systemfunktionen/anmodningen, som kan udføres med beføjelsen);
- beskrivelse af beføjelsen (detaljeret beskrivelse af handlinger i IS ved anvendelse af beføjelsen og deres konsekvenser for processen;
- status for beføjelsen: "Aktiv" (hvis beføjelsen er tildelt mindst én bruger) eller "Inaktiv" (hvis beføjelsen ikke anvendes).
Trin 6 Henter data om brugere og rettigheder fra systemer og sammenligner med personaleoplysningerne.
I den afsluttende fase af forberedelsen er det nødvendigt at eksportere data fra informationssystemerne om alle brugere og de rettigheder, de har i øjeblikket. Her er der to mulige scenarier. Den første: sikkerhedsafdelingen har direkte adgang til systemet og har midler til at eksportere de relevante rapporter, hvilket sjældent er tilfældet, men det er meget praktisk. Den anden: vi sender en anmodning til IT om at få rapporter i det ønskede format. Praksis viser: at blive enige med IT og få de nødvendige data fra første forsøg sker sjældent. Man skal gøre flere forsøg, indtil informationen er modtaget i det rigtige format og form.
Hvilke data skal eksporteres:
- Navn på brugerkonto
- Navn på medarbejderen, som den er knyttet til
- Status (aktiv eller blokeret)
- Dato for oprettelse af brugerkonto
- Dato for seneste brug
- Liste over tilgængelige rettigheder/grupper/roller
Så vi har fået eksporten fra systemet med alle brugere og alle rettigheder, der er givet dem. Og vi har straks lagt alle blokerede konti til side, da arbejdet med at opbygge den rollebaserede model kun vil finde sted for aktive brugere.
Derefter, hvis din virksomhed ikke har automatiserede midler til at lukke adgangen for afskedige medarbejdere (det er ikke ualmindeligt), eller hvis der er patchwork-automatisering, der ikke altid fungerer korrekt, skal alle 'døde sjæle' identificeres. Det handler om brugerkonti for allerede afskedigede medarbejdere, hvis rettigheder af en eller anden grund ikke er blevet blokeret – de skal blokeres. For at gøre dette sammenlignes de eksporterede data med personalekilden. Den personaleeksport skal også først indhentes fra den afdeling, der fører personalebasen.
Det er nødvendigt at adskille de konti, hvis ejere ikke er fundet i medarbejderdatan, og som ikke er knyttet til nogen – det vil sige, forladte. Til denne liste har vi brug for datoen for den sidste brug: hvis den er relativt ny, skal vi stadig forsøge at finde ejere. Dette kan inkludere konti til eksterne entreprenører eller servicekonti, der ikke er knyttet til nogen, men som er relateret til visse processer. For at afgøre ejerskabet af konti kan der sendes breve til alle afdelinger med anmodning om at svare. Når ejerne er fundet, indtaster vi deres oplysninger i systemet: på denne måde er alle aktive konti identificeret, og de resterende bliver blokeret.
Når vores eksport er renset for overflødige poster og kun aktive konti er tilbage, kan vi begynde at opbygge en rollemodel for det specifikke informationssystem. Men dette vil jeg fortælle om i næste artikel.
Forfatter: Lyudmila Sevastyanova, marketing manager hos Solar inRights
Kilde: habr.com
