{"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\/sv\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","title":{"rendered":"Bygger en rollmodell f\u00f6r \u00e5tkomsthantering. Del ett, f\u00f6rberedande","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Just nu arbetar jag p\u00e5 ett programvaruv\u00e4rdskap, specifikt med l\u00f6sningar f\u00f6r \u00e5tkomsthantering. Min erfarenhet \"fr\u00e5n mitt f\u00f6rra liv\" \u00e4r kopplad till best\u00e4llarsidan \u2013 en stor finansiell organisation. D\u00e5 hade v\u00e5r \u00e5tkomstkontrollgrupp inom IT-s\u00e4kerhetsavdelningen inte stora kompetenser inom IdM. Vi l\u00e4rde oss mycket genom processen, och det blev m\u00e5nga misstag innan vi lyckades bygga en fungerande mekanism f\u00f6r hantering av anv\u00e4ndarr\u00e4ttigheter i informationssystemen.
\n\"Bygger
\nGenom att kombinera min erfarenhet fr\u00e5n best\u00e4llarsidan med kunskaper och kompetenser fr\u00e5n leverant\u00f6ren, vill jag dela med mig av vad som i grunden \u00e4r en steg-f\u00f6r-steg-instruktion f\u00f6r hur man skapar en rollbaserad \u00e5tkomstmodell i ett stort f\u00f6retag och vad detta kan ge i slut\u00e4ndan. Min instruktion best\u00e5r av tv\u00e5 delar: den f\u00f6rsta \u2013 att f\u00f6rbereda sig f\u00f6r att bygga modellen, den andra \u2013 sj\u00e4lva byggandet. H\u00e4r presenterar jag den f\u00f6rsta delen, f\u00f6rberedelsen.
\n<\/a><\/noindex>
\nN.B.<\/b> Att bygga en rollmodell \u00e4r tyv\u00e4rr inte ett resultat, utan en process. Snarare \u00e4r det en del av processen f\u00f6r att skapa ett ekosystem f\u00f6r \u00e5tkomsthantering inom f\u00f6retaget. S\u00e5 var beredd p\u00e5 att spela l\u00e5ngsiktigt.
\n<\/i>
\nL\u00e5t oss f\u00f6rst klarg\u00f6ra \u2013 vad inneb\u00e4r egentligen rollbaserad \u00e5tkomsthantering? Anta att du har en stor bank med tiotusentals, kanske hundratusentals anst\u00e4llda (subjekt), d\u00e4r varje anst\u00e4lld har tiotals r\u00e4ttigheter till hundratals interna informationssystem (objekt). Multiplicera nu antalet objekt med antalet subjekt \u2013 s\u00e5 m\u00e5nga relationer beh\u00f6ver du f\u00f6rst skapa och sedan kontrollera. \u00c4r det realistiskt att g\u00f6ra det manuellt? Sj\u00e4lvklart inte \u2013 f\u00f6r att l\u00f6sa den h\u00e4r uppgiften skapades roller.<\/p>\n

En roll \u00e4r en upps\u00e4ttning beh\u00f6righeter som en anv\u00e4ndare eller en grupp anv\u00e4ndare beh\u00f6ver f\u00f6r att utf\u00f6ra specifika arbetsuppgifter. Varje anst\u00e4lld kan ha en eller flera roller, och varje roll kan inneh\u00e5lla fr\u00e5n en till m\u00e5nga beh\u00f6righeter som \u00e4r till\u00e5tna f\u00f6r anv\u00e4ndaren inom ramen f\u00f6r denna roll. Roller kan kopplas till specifika befattningar, avdelningar eller funktionella arbetsuppgifter.<\/p>\n

\"Bygger
\n
\nRoller skapas vanligtvis fr\u00e5n individuella befogenheter f\u00f6r anst\u00e4llda i varje informationssystem. D\u00e4refter bildas globala aff\u00e4rsroller fr\u00e5n rollerna i varje system. Till exempel kommer aff\u00e4rsrollen \"kreditchef\" att inkludera flera individuella roller i informationssystem som anv\u00e4nds i bankens kundkontor. L\u00e5t oss s\u00e4ga, i s\u00e5dana som det huvudsakliga automatiserade banksystemet, kassamodulen, systemet f\u00f6r elektronisk dokumenthantering, tj\u00e4nstehanteraren och andra. Aff\u00e4rsroller kopplas vanligtvis till den organisatoriska och anst\u00e4llningsstrukturen \u2013 enklare sagt, till upps\u00e4ttningen av f\u00f6retagsavdelningar och befattningar inom dem. S\u00e5 bildas den globala rollmatrisen (ett exempel finns i tabellen nedan).<\/p>\n

\"Bygger
\n
\nDet b\u00f6r noteras att det \u00e4r helt om\u00f6jligt att bygga en 100%-ig rollmodell som ger alla n\u00f6dv\u00e4ndiga r\u00e4ttigheter f\u00f6r anst\u00e4llda i en kommersiell struktur. Och det \u00e4r inte n\u00f6dv\u00e4ndigt. Rollmodellen kan inte vara statisk, eftersom den beror p\u00e5 en st\u00e4ndigt f\u00f6r\u00e4ndrad omgivning. Och p\u00e5 f\u00f6r\u00e4ndringar i f\u00f6retagets aff\u00e4rsverksamhet, som i sin tur p\u00e5verkar f\u00f6r\u00e4ndringar i organisationsstrukturen och funktionaliteten. Och p\u00e5 bristen p\u00e5 fulla resurser, och p\u00e5 bristande efterlevnad av arbetsbeskrivningar, och p\u00e5 str\u00e4van efter vinst p\u00e5 bekostnad av s\u00e4kerheten, och p\u00e5 m\u00e5nga andra faktorer. D\u00e4rf\u00f6r m\u00e5ste man bygga en rollmodell som kan tillgodose upp till 80% av anv\u00e4ndarnas behov av n\u00f6dv\u00e4ndiga grundl\u00e4ggande r\u00e4ttigheter vid utn\u00e4mning till tj\u00e4nst. De resterande 20% kan de, om det beh\u00f6vs, beg\u00e4ra senare genom separata ans\u00f6kningar.<\/p>\n

Sj\u00e4lvklart kan du fr\u00e5ga: \"Finns det inte \u00f6verhuvudtaget 100%-iga rollmodeller?\" Jo, s\u00e5dan f\u00f6rekommer, till exempel i ideella strukturer som inte uts\u00e4tts f\u00f6r frekventa f\u00f6r\u00e4ndringar, \u2013 i n\u00e5got forskningsinstitut. Eller i organisationer inom f\u00f6rsvarsindustrin med h\u00f6g s\u00e4kerhetsniv\u00e5, d\u00e4r s\u00e4kerhet st\u00e5r h\u00f6gst p\u00e5 agendan. Det f\u00f6rekommer ocks\u00e5 inom kommersiella strukturer, men inom en specifik avdelning, vars arbete \u00e4r en ganska statisk och f\u00f6ruts\u00e4gbar process.<\/p>\n

Den st\u00f6rsta f\u00f6rdelen med rollstyrning \u00e4r att det f\u00f6renklar tilldelningen av r\u00e4ttigheter, eftersom antalet roller \u00e4r avsev\u00e4rt mindre \u00e4n antalet anv\u00e4ndare i informationssystemet. Detta g\u00e4ller f\u00f6r alla branscher.<\/p>\n

L\u00e5t oss ta ett detaljhandelsf\u00f6retag: tusentals s\u00e4ljare arbetar d\u00e4r, men de har samma r\u00e4ttigheter i system N, och endast en roll kommer att skapas f\u00f6r dem. N\u00e4r en ny s\u00e4ljare kommer till f\u00f6retaget tilldelas de automatiskt den n\u00f6dv\u00e4ndiga rollen i systemet, d\u00e4r alla n\u00f6dv\u00e4ndiga befogenheter redan finns. P\u00e5 samma s\u00e4tt kan r\u00e4ttigheter f\u00f6r tusentals s\u00e4ljare \u00e4ndras med ett enda klick, till exempel genom att l\u00e4gga till ett nytt alternativ f\u00f6r rapportgenerering. Det beh\u00f6vs inte tusen operationer f\u00f6r att koppla den nya r\u00e4ttigheten till varje konto \u2013 det r\u00e4cker att inf\u00f6ra detta alternativ i rollen, och det kommer att bli synligt f\u00f6r alla s\u00e4ljare samtidigt.<\/p>\n

En annan f\u00f6rdel med rollbaserad hantering \u00e4r uteslutandet av att tilldela of\u00f6renliga r\u00e4ttigheter. Det vill s\u00e4ga en anst\u00e4lld som har en specifik roll i systemet kan inte samtidigt ha en annan roll vars r\u00e4ttigheter inte b\u00f6r kombineras med r\u00e4ttigheterna i den f\u00f6rsta. Ett tydligt exempel \u00e4r f\u00f6rbudet mot att kombinera funktioner f\u00f6r inmatning och kontroll av finansiella transaktioner.<\/p>\n

F\u00f6r alla som \u00e4r intresserade av hur rollbaserad \u00e5tkomsthantering faktiskt kom till, kan
\n dyka ner i en historisk \u00f6versikt<\/b>
\n Om vi g\u00e5r tillbaka till historien, s\u00e5 b\u00f6rjade IT-gemenskapen fundera p\u00e5 metoder f\u00f6r \u00e5tkomsthantering redan p\u00e5 1970-talet. \u00c4ven om applikationerna d\u00e5 var ganska enkla, ville alla, precis som nu, ha en bekv\u00e4m kontroll \u00f6ver \u00e5tkomsten till dem. Att tilldela, f\u00f6r\u00e4ndra och kontrollera anv\u00e4ndarr\u00e4ttigheter \u2013 bara f\u00f6r att g\u00f6ra det l\u00e4ttare att f\u00f6rst\u00e5 vilken \u00e5tkomst varje anv\u00e4ndare har. Men p\u00e5 den tiden fanns det inga gemensamma standarder; de f\u00f6rsta systemen f\u00f6r \u00e5tkomsthantering utvecklades, och varje f\u00f6retag baserade sina system p\u00e5 sina egna uppfattningar och regler.<\/p>\n

Nu finns det m\u00e5nga olika modeller f\u00f6r \u00e5tkomsthantering, men de har inte dykt upp omedelbart. L\u00e5t oss stanna upp vid de som har gjort ett betydande bidrag till utvecklingen av detta omr\u00e5de.<\/p>\n

Den f\u00f6rsta och kanske enklaste modellen \u00e4r Diskretion\u00e4r (valfri) \u00e5tkomsthantering<\/b> (DAC \u2013 Discretionary access control). Denna modell inneb\u00e4r att r\u00e4ttigheterna delas av alla deltagare i \u00e5tkomstprocessen. Varje anv\u00e4ndare f\u00e5r tillg\u00e5ng till specifika objekt eller \u00e5tg\u00e4rder. I grunden motsvarar m\u00e5nga r\u00e4ttighetssubjekt m\u00e5nga objekt. Denna modell har bed\u00f6mts som f\u00f6r flexibel och f\u00f6r komplicerad att underh\u00e5lla: \u00e5tkomstlistor blir med tiden enorma och sv\u00e5ra att kontrollera.<\/p>\n

Den andra modellen \u00e4r Obligatorisk \u00e5tkomstkontroll (MAC \u2014 Mandatory access control)<\/b>. Enligt denna modell f\u00e5r varje anv\u00e4ndare tillg\u00e5ng till ett objekt i enlighet med beviljad \u00e5tkomst till en viss niv\u00e5 av dataskydd. D\u00e4rf\u00f6r m\u00e5ste objekten kategoriseras efter skyddsniv\u00e5. Till skillnad fr\u00e5n den f\u00f6rsta flexibla modellen visade sig denna vara f\u00f6r strikt och begr\u00e4nsande. Dess anv\u00e4ndning \u00e4r inte motiverad n\u00e4r ett f\u00f6retag har m\u00e5nga olika informationsresurser: f\u00f6r att kunna begr\u00e4nsa \u00e5tkomst till olika resurser m\u00e5ste man inf\u00f6ra m\u00e5nga kategorier som inte kommer att \u00f6verlappa.<\/p>\n

Med tanke p\u00e5 de uppenbara bristerna i dessa tv\u00e5 metoder fortsatte IT-gemenskapen att utveckla modeller som \u00e4r mer flexibla och samtidigt mer eller mindre universella f\u00f6r att st\u00f6dja olika typer av organisatoriska \u00e5tkomstkontrollpolicys. Och d\u00e5 kom den tredje modellen f\u00f6r rollbaserad \u00e5tkomstkontroll!<\/b> Denna metod har visat sig vara den mest lovande, eftersom den kr\u00e4ver inte bara autentisering av anv\u00e4ndarens identitet utan ocks\u00e5 av hans arbetsfunktioner i systemen.<\/p>\n

Den f\u00f6rsta tydligt beskrivna strukturen f\u00f6r den rollbaserade modellen f\u00f6reslogs av de amerikanska forskarna David Ferraiolo och Richard Kuhn vid National Institute of Standards and Technology i USA 1992. Det var d\u00e5 termen RBAC (Role-based access control) f\u00f6rst d\u00f6k upp. <\/b>Dessa studier och beskrivningar av de grundl\u00e4ggande komponenterna samt deras samband utg\u00f6r grunden f\u00f6r den fortfarande g\u00e4llande standarden INCITS 359-2012, som godk\u00e4nts av International Committee for Information Technology Standards (INCITS).<\/p>\n

Standarden definierar en roll som \"en funktion inom en organisation med viss relaterad semantik kopplad till befogenheter och ansvar som \u00e5l\u00e4ggs en anv\u00e4ndare som tilldelats rollen\". Dokumentet fastst\u00e4ller de grundl\u00e4ggande elementen i RBAC \u2013 anv\u00e4ndare, sessioner, roller, beh\u00f6righeter, operationer och objekt, samt relationerna och f\u00f6rh\u00e5llandena mellan dessa.<\/p>\n

Standarden ger en minimalt n\u00f6dv\u00e4ndig struktur f\u00f6r att bygga en rollmodell \u2013 att samla r\u00e4ttigheter i roller och sedan ge \u00e5tkomst till anv\u00e4ndarna genom dessa roller. Det anges mekanismer f\u00f6r att skapa roller fr\u00e5n objekt och operationer, och hierarkin av roller och arv av befogenheter beskrivs. I varje f\u00f6retag finns det roller som f\u00f6renar element\u00e4ra befogenheter som alla anst\u00e4llda beh\u00f6ver. Detta kan vara \u00e5tkomst till e-post, till DMS, till f\u00f6retagets portal osv. Dessa befogenheter kan inkluderas i en gemensam roll kallad \"anst\u00e4lld\", och det beh\u00f6ver inte anges i varje h\u00f6gre roll alla element\u00e4ra r\u00e4ttigheter g\u00e5ng p\u00e5 g\u00e5ng. Det r\u00e4cker med att ange arvsegenskapen f\u00f6r rollen \"anst\u00e4lld\".<\/p>\n

\"Bygger
\n
\nSenare kompletterades standarden med nya \u00e5tkomstattribut relaterade till det st\u00e4ndigt f\u00f6r\u00e4nderliga omgivningen. M\u00f6jligheten till inf\u00f6rande av statiska och dynamiska begr\u00e4nsningar lades till. Statiska inneb\u00e4r of\u00f6rm\u00e5ga att kombinera roller (den n\u00e4mnda inf\u00f6ringen och kontrollen av operationer ovan). Dynamiska begr\u00e4nsningar kan definieras av f\u00f6r\u00e4nderliga parametrar, som tid (arbets-\/icke-arbetstimmar eller dagar), plats (kontor\/hem) osv.<\/p>\n

Det \u00e4r s\u00e4rskilt v\u00e4rt att n\u00e4mna attributbaserad \u00e5tkomstkontroll (ABAC \u2013 Attribute-based access control).<\/b> Tillv\u00e4gag\u00e5ngss\u00e4ttet bygger p\u00e5 att ge \u00e5tkomst genom regler f\u00f6r delning av attribut. Denna modell kan anv\u00e4ndas separat, men ofta kompletterar den aktivt den klassiska rollmodellen: man kan l\u00e4gga till anv\u00e4ndarattribut, resursattribut och enhetsattribut, samt tids- eller platsspecifika attribut till en viss roll. Detta m\u00f6jligg\u00f6r anv\u00e4ndning av f\u00e4rre roller, inf\u00f6rande av ytterligare begr\u00e4nsningar och att g\u00f6ra \u00e5tkomsten tillr\u00e4ckligt minimal, vilket i sin tur \u00f6kar s\u00e4kerheten.<\/p>\n

Till exempel kan en revisor ges tillg\u00e5ng till konton om han arbetar i ett visst omr\u00e5de. D\u00e5 kommer specialistens plats att j\u00e4mf\u00f6ras med ett visst referensv\u00e4rde. Det g\u00e5r ocks\u00e5 att ge \u00e5tkomst till konton endast om anv\u00e4ndaren loggar in fr\u00e5n en enhet som finns registrerad som till\u00e5ten. En bra till\u00e4gg till den rollbaserade modellen, men den anv\u00e4nds s\u00e4llan ensamt p\u00e5 grund av behovet av att skapa m\u00e5nga regler och tabeller f\u00f6r \u00e5tkomster eller begr\u00e4nsningar.<\/p>\n

Jag ger ett exempel p\u00e5 till\u00e4mpning av ABAC fr\u00e5n mitt \"f\u00f6rflutna liv\". V\u00e5r bank hade flera filialer. Anst\u00e4llda i kundkontoren i dessa filialer utf\u00f6rde helt identiska operationer, men de var endast beh\u00f6riga att arbeta i det centrala systemet med konton i sitt eget omr\u00e5de. F\u00f6rst b\u00f6rjade vi skapa separata roller f\u00f6r varje region \u2013 och det blev v\u00e4ldigt m\u00e5nga roller med upprepande funktionalitet, men med \u00e5tkomst till olika konton! Sedan, genom att anv\u00e4nda anv\u00e4ndarens platsattribut och koppla det till ett specifikt intervall av konton f\u00f6r kontroll, minskade vi betydligt antalet roller i systemet. Som resultat kvarstod endast roller f\u00f6r en filial, som kopierades till motsvarande tj\u00e4nster i alla andra territoriala avdelningar i banken.<\/p>\n

Och nu pratar vi om n\u00f6dv\u00e4ndiga f\u00f6rberedande steg utan vilka det \u00e4r om\u00f6jligt att bygga en fungerande rollmodell.<\/p>\n

Steg 1. Skapa en funktionell modell<\/h2>\n

\nDet b\u00f6rjar med att skapa en funktionsmodell \u2013 ett \u00f6vergripande dokument d\u00e4r funktionaliteten f\u00f6r varje avdelning och varje tj\u00e4nst beskrivs i detalj. Informationen kommer vanligen fr\u00e5n olika dokument: tj\u00e4nstebeskrivningar och f\u00f6reskrifter f\u00f6r enskilda avdelningar \u2013 kontor, enheter, avdelningar. Funktionsmodellen ska godk\u00e4nnas av alla ber\u00f6rda avdelningar (aff\u00e4r, intern kontroll, s\u00e4kerhet) och godk\u00e4nnas av f\u00f6retagets ledning. Vad beh\u00f6vs detta dokument till? F\u00f6r att den rollbaserade modellen ska kunna referera till det. Till exempel, om du planerar att bygga en rollbaserad modell baserat p\u00e5 redan existerande r\u00e4ttigheter fr\u00e5n anst\u00e4llda \u2013 h\u00e4mtade fr\u00e5n systemet och<\/p>\n

Steg 2. Vi auditerar IT-system och uppr\u00e4ttar en prioriteringsplan<\/h2>\n

\nUnder det andra steget ska en revision av IT-system genomf\u00f6ras f\u00f6r att f\u00f6rst\u00e5 hur tillg\u00e5ngen till dem \u00e4r organiserad. Till exempel, i mitt finansiella f\u00f6retag fanns det flera hundra informationssystem. I alla dessa system fanns det vissa former av rollhantering, i de flesta system \u2013 n\u00e5gra roller, men mest p\u00e5 papper eller i systemets katalog \u2013 de hade l\u00e4nge blivit f\u00f6r\u00e5ldrade, och tillg\u00e5ngen till dem gavs ut baserat p\u00e5 faktiska anv\u00e4ndningsf\u00f6rfr\u00e5gningar. Naturligtvis \u00e4r det helt om\u00f6jligt att bygga en rollbaserad modell direkt i ett par hundra system, man m\u00e5ste b\u00f6rja n\u00e5gonstans. Vi genomf\u00f6rde en djupg\u00e5ende analys av tillg\u00e5ngshanteringsprocessen f\u00f6r att best\u00e4mma dess mognadsniv\u00e5. Under analysen utvecklades kriterier f\u00f6r prioritering av informationssystem \u2013 kritikalitet, beredskap, planer f\u00f6r avveckling osv. Med hj\u00e4lp av dessa kriterier ordnade vi prioriteringarna f\u00f6r utveckling\/uppdatering av de rollbaserade modellerna f\u00f6r dessa system. D\u00e4refter integrerade vi de rollbaserade modellerna i en plan f\u00f6r integration med l\u00f6sningen f\u00f6r identitetshantering, f\u00f6r att automatisera tillg\u00e5ngshanteringen.<\/p>\n

S\u00e5, hur definierar man systemets kritikalitet? Svara p\u00e5 f\u00f6ljande fr\u00e5gor:<\/p>\n