Bygger en rollmodell för åtkomsthantering. Del ett, förberedande

Just nu arbetar jag på ett programvaruvärdskap, specifikt med lösningar för åtkomsthantering. Min erfarenhet "från mitt förra liv" är kopplad till beställarsidan – en stor finansiell organisation. Då hade vår åtkomstkontrollgrupp inom IT-säkerhetsavdelningen inte stora kompetenser inom IdM. Vi lärde oss mycket genom processen, och det blev många misstag innan vi lyckades bygga en fungerande mekanism för hantering av användarrättigheter i informationssystemen.

Genom att kombinera min erfarenhet från beställarsidan med kunskaper och kompetenser från leverantören, vill jag dela med mig av vad som i grunden är en steg-för-steg-instruktion för hur man skapar en rollbaserad åtkomstmodell i ett stort företag och vad detta kan ge i slutändan. Min instruktion består av två delar: den första – att förbereda sig för att bygga modellen, den andra – själva byggandet. Här presenterar jag den första delen, förberedelsen.

N.B. Att bygga en rollmodell är tyvärr inte ett resultat, utan en process. Snarare är det en del av processen för att skapa ett ekosystem för åtkomsthantering inom företaget. Så var beredd på att spela långsiktigt.

Låt oss först klargöra – vad innebär egentligen rollbaserad åtkomsthantering? Anta att du har en stor bank med tiotusentals, kanske hundratusentals anställda (subjekt), där varje anställd har tiotals rättigheter till hundratals interna informationssystem (objekt). Multiplicera nu antalet objekt med antalet subjekt – så många relationer behöver du först skapa och sedan kontrollera. Är det realistiskt att göra det manuellt? Självklart inte – för att lösa den här uppgiften skapades roller.

En roll är en uppsättning behörigheter som en användare eller en grupp användare behöver för att utföra specifika arbetsuppgifter. Varje anställd kan ha en eller flera roller, och varje roll kan innehålla från en till många behörigheter som är tillåtna för användaren inom ramen för denna roll. Roller kan kopplas till specifika befattningar, avdelningar eller funktionella arbetsuppgifter.

Roller skapas vanligtvis från individuella befogenheter för anställda i varje informationssystem. Därefter bildas globala affärsroller från rollerna i varje system. Till exempel kommer affärsrollen "kreditchef" att inkludera flera individuella roller i informationssystem som används i bankens kundkontor. Låt oss säga, i sådana som det huvudsakliga automatiserade banksystemet, kassamodulen, systemet för elektronisk dokumenthantering, tjänstehanteraren och andra. Affärsroller kopplas vanligtvis till den organisatoriska och anställningsstrukturen – enklare sagt, till uppsättningen av företagsavdelningar och befattningar inom dem. Så bildas den globala rollmatrisen (ett exempel finns i tabellen nedan).

Det bör noteras att det är helt omöjligt att bygga en 100%-ig rollmodell som ger alla nödvändiga rättigheter för anställda i en kommersiell struktur. Och det är inte nödvändigt. Rollmodellen kan inte vara statisk, eftersom den beror på en ständigt förändrad omgivning. Och på förändringar i företagets affärsverksamhet, som i sin tur påverkar förändringar i organisationsstrukturen och funktionaliteten. Och på bristen på fulla resurser, och på bristande efterlevnad av arbetsbeskrivningar, och på strävan efter vinst på bekostnad av säkerheten, och på många andra faktorer. Därför måste man bygga en rollmodell som kan tillgodose upp till 80% av användarnas behov av nödvändiga grundläggande rättigheter vid utnämning till tjänst. De resterande 20% kan de, om det behövs, begära senare genom separata ansökningar.

Självklart kan du fråga: "Finns det inte överhuvudtaget 100%-iga rollmodeller?" Jo, sådan förekommer, till exempel i ideella strukturer som inte utsätts för frekventa förändringar, – i något forskningsinstitut. Eller i organisationer inom försvarsindustrin med hög säkerhetsnivå, där säkerhet står högst på agendan. Det förekommer också inom kommersiella strukturer, men inom en specifik avdelning, vars arbete är en ganska statisk och förutsägbar process.

Den största fördelen med rollstyrning är att det förenklar tilldelningen av rättigheter, eftersom antalet roller är avsevärt mindre än antalet användare i informationssystemet. Detta gäller för alla branscher.

Låt oss ta ett detaljhandelsföretag: tusentals säljare arbetar där, men de har samma rättigheter i system N, och endast en roll kommer att skapas för dem. När en ny säljare kommer till företaget tilldelas de automatiskt den nödvändiga rollen i systemet, där alla nödvändiga befogenheter redan finns. På samma sätt kan rättigheter för tusentals säljare ändras med ett enda klick, till exempel genom att lägga till ett nytt alternativ för rapportgenerering. Det behövs inte tusen operationer för att koppla den nya rättigheten till varje konto – det räcker att införa detta alternativ i rollen, och det kommer att bli synligt för alla säljare samtidigt.

En annan fördel med rollbaserad hantering är uteslutandet av att tilldela oförenliga rättigheter. Det vill säga en anställd som har en specifik roll i systemet kan inte samtidigt ha en annan roll vars rättigheter inte bör kombineras med rättigheterna i den första. Ett tydligt exempel är förbudet mot att kombinera funktioner för inmatning och kontroll av finansiella transaktioner.

För alla som är intresserade av hur rollbaserad åtkomsthantering faktiskt kom till, kan
dyka ner i en historisk översikt
Om vi går tillbaka till historien, så började IT-gemenskapen fundera på metoder för åtkomsthantering redan på 1970-talet. Även om applikationerna då var ganska enkla, ville alla, precis som nu, ha en bekväm kontroll över åtkomsten till dem. Att tilldela, förändra och kontrollera användarrättigheter – bara för att göra det lättare att förstå vilken åtkomst varje användare har. Men på den tiden fanns det inga gemensamma standarder; de första systemen för åtkomsthantering utvecklades, och varje företag baserade sina system på sina egna uppfattningar och regler.

Nu finns det många olika modeller för åtkomsthantering, men de har inte dykt upp omedelbart. Låt oss stanna upp vid de som har gjort ett betydande bidrag till utvecklingen av detta område.

Den första och kanske enklaste modellen är Diskretionär (valfri) åtkomsthantering (DAC – Discretionary access control). Denna modell innebär att rättigheterna delas av alla deltagare i åtkomstprocessen. Varje användare får tillgång till specifika objekt eller åtgärder. I grunden motsvarar många rättighetssubjekt många objekt. Denna modell har bedömts som för flexibel och för komplicerad att underhålla: åtkomstlistor blir med tiden enorma och svåra att kontrollera.

Den andra modellen är Obligatorisk åtkomstkontroll (MAC — Mandatory access control). Enligt denna modell får varje användare tillgång till ett objekt i enlighet med beviljad åtkomst till en viss nivå av dataskydd. Därför måste objekten kategoriseras efter skyddsnivå. Till skillnad från den första flexibla modellen visade sig denna vara för strikt och begränsande. Dess användning är inte motiverad när ett företag har många olika informationsresurser: för att kunna begränsa åtkomst till olika resurser måste man införa många kategorier som inte kommer att överlappa.

Med tanke på de uppenbara bristerna i dessa två metoder fortsatte IT-gemenskapen att utveckla modeller som är mer flexibla och samtidigt mer eller mindre universella för att stödja olika typer av organisatoriska åtkomstkontrollpolicys. Och då kom den tredje modellen för rollbaserad åtkomstkontroll! Denna metod har visat sig vara den mest lovande, eftersom den kräver inte bara autentisering av användarens identitet utan också av hans arbetsfunktioner i systemen.

Den första tydligt beskrivna strukturen för den rollbaserade modellen föreslogs av de amerikanska forskarna David Ferraiolo och Richard Kuhn vid National Institute of Standards and Technology i USA 1992. Det var då termen RBAC (Role-based access control) först dök upp. Dessa studier och beskrivningar av de grundläggande komponenterna samt deras samband utgör grunden för den fortfarande gällande standarden INCITS 359-2012, som godkänts av International Committee for Information Technology Standards (INCITS).

Standarden definierar en roll som "en funktion inom en organisation med viss relaterad semantik kopplad till befogenheter och ansvar som åläggs en användare som tilldelats rollen". Dokumentet fastställer de grundläggande elementen i RBAC – användare, sessioner, roller, behörigheter, operationer och objekt, samt relationerna och förhållandena mellan dessa.

Standarden ger en minimalt nödvändig struktur för att bygga en rollmodell – att samla rättigheter i roller och sedan ge åtkomst till användarna genom dessa roller. Det anges mekanismer för att skapa roller från objekt och operationer, och hierarkin av roller och arv av befogenheter beskrivs. I varje företag finns det roller som förenar elementära befogenheter som alla anställda behöver. Detta kan vara åtkomst till e-post, till DMS, till företagets portal osv. Dessa befogenheter kan inkluderas i en gemensam roll kallad "anställd", och det behöver inte anges i varje högre roll alla elementära rättigheter gång på gång. Det räcker med att ange arvsegenskapen för rollen "anställd".

Senare kompletterades standarden med nya åtkomstattribut relaterade till det ständigt föränderliga omgivningen. Möjligheten till införande av statiska och dynamiska begränsningar lades till. Statiska innebär oförmåga att kombinera roller (den nämnda införingen och kontrollen av operationer ovan). Dynamiska begränsningar kan definieras av föränderliga parametrar, som tid (arbets-/icke-arbetstimmar eller dagar), plats (kontor/hem) osv.

Det är särskilt värt att nämna attributbaserad åtkomstkontroll (ABAC – Attribute-based access control). Tillvägagångssättet bygger på att ge åtkomst genom regler för delning av attribut. Denna modell kan användas separat, men ofta kompletterar den aktivt den klassiska rollmodellen: man kan lägga till användarattribut, resursattribut och enhetsattribut, samt tids- eller platsspecifika attribut till en viss roll. Detta möjliggör användning av färre roller, införande av ytterligare begränsningar och att göra åtkomsten tillräckligt minimal, vilket i sin tur ökar säkerheten.

Till exempel kan en revisor ges tillgång till konton om han arbetar i ett visst område. Då kommer specialistens plats att jämföras med ett visst referensvärde. Det går också att ge åtkomst till konton endast om användaren loggar in från en enhet som finns registrerad som tillåten. En bra tillägg till den rollbaserade modellen, men den används sällan ensamt på grund av behovet av att skapa många regler och tabeller för åtkomster eller begränsningar.

Jag ger ett exempel på tillämpning av ABAC från mitt "förflutna liv". Vår bank hade flera filialer. Anställda i kundkontoren i dessa filialer utförde helt identiska operationer, men de var endast behöriga att arbeta i det centrala systemet med konton i sitt eget område. Först började vi skapa separata roller för varje region – och det blev väldigt många roller med upprepande funktionalitet, men med åtkomst till olika konton! Sedan, genom att använda användarens platsattribut och koppla det till ett specifikt intervall av konton för kontroll, minskade vi betydligt antalet roller i systemet. Som resultat kvarstod endast roller för en filial, som kopierades till motsvarande tjänster i alla andra territoriala avdelningar i banken.

Och nu pratar vi om nödvändiga förberedande steg utan vilka det är omöjligt att bygga en fungerande rollmodell.

Steg 1. Skapa en funktionell modell

Det börjar med att skapa en funktionsmodell – ett övergripande dokument där funktionaliteten för varje avdelning och varje tjänst beskrivs i detalj. Informationen kommer vanligen från olika dokument: tjänstebeskrivningar och föreskrifter för enskilda avdelningar – kontor, enheter, avdelningar. Funktionsmodellen ska godkännas av alla berörda avdelningar (affär, intern kontroll, säkerhet) och godkännas av företagets ledning. Vad behövs detta dokument till? För att den rollbaserade modellen ska kunna referera till det. Till exempel, om du planerar att bygga en rollbaserad modell baserat på redan existerande rättigheter från anställda – hämtade från systemet och

Steg 2. Vi auditerar IT-system och upprättar en prioriteringsplan

Under det andra steget ska en revision av IT-system genomföras för att förstå hur tillgången till dem är organiserad. Till exempel, i mitt finansiella företag fanns det flera hundra informationssystem. I alla dessa system fanns det vissa former av rollhantering, i de flesta system – några roller, men mest på papper eller i systemets katalog – de hade länge blivit föråldrade, och tillgången till dem gavs ut baserat på faktiska användningsförfrågningar. Naturligtvis är det helt omöjligt att bygga en rollbaserad modell direkt i ett par hundra system, man måste börja någonstans. Vi genomförde en djupgående analys av tillgångshanteringsprocessen för att bestämma dess mognadsnivå. Under analysen utvecklades kriterier för prioritering av informationssystem – kritikalitet, beredskap, planer för avveckling osv. Med hjälp av dessa kriterier ordnade vi prioriteringarna för utveckling/uppdatering av de rollbaserade modellerna för dessa system. Därefter integrerade vi de rollbaserade modellerna i en plan för integration med lösningen för identitetshantering, för att automatisera tillgångshanteringen.

Så, hur definierar man systemets kritikalitet? Svara på följande frågor:

• Är systemet kopplat till de operativa processer som är avgörande för företagets grundverksamhet?
• Kommer störningar i systemets funktion att påverka integriteten av företagets tillgångar?
• Vad är den maximalt tillåtna tiden för driftstopp, efter vilken verksamheten inte längre kan återställas efter avbrott?
• Kan en överträdelse av informationens integritet i systemet leda till irreversibla konsekvenser, både finansiella och rykte?
• Känslighet för bedrägeri. Förekomsten av funktionalitet som, utan tillräcklig kontroll, kan möjliggöra interna/externa bedrägliga åtgärder;
• Vad är kraven enligt lagstiftningen samt interna regler och procedurer för dessa system? Kommer det att bli böter från myndigheter för överträdelser?

I vårt finansiella företag genomförde vi en revision på detta sätt. Ledningen utvecklade en procedur för revision av Access Right Review för att förstå befintliga användare och rättigheter, först i de informationssystem som kommit på prioritetslistan. Säkerhetsavdelningen utsågs till ägare av denna process. Men för att få en fullständig bild av åtkomsträttigheterna i företaget var det nödvändigt att involvera IT- och affärsavdelningarna i processen. Och här började tvister, missförstånd och ibland till och med sabotage: ingen vill avbryta sina nuvarande uppgifter och delta i vad som vid första anblick kan verka som obehagliga aktiviteter.

N.B. Stora företag med väletablerade IT-processer är säkert bekanta med IT-revisionsproceduren - IT general controls (ITGC), som gör det möjligt att identifiera brister i IT-processerna och etablera kontroll så att processerna förbättras i enlighet med best practice (ITIL, COBIT, IT Governance m.m.). Sådan revision möjliggör för IT och affär att bättre förstå varandra och utveckla en gemensam strategisk plan, analysera risker, optimera kostnader och utveckla mer effektiva arbetsmetoder.



Ett av områdena inom revision är att fastställa parametrarna för logisk och fysisk åtkomst till informationssystem. De insamlade uppgifterna har vi använt som grund för vidare användning vid skapandet av en rollmodell. Som ett resultat av denna revision har vi fått ett register över IT-system, där deras tekniska parametrar har definierats och beskrivningar har givits. Dessutom har en ägare från affärsområdet fastställts för varje system, i vars intresse det utnyttjades: det är han som ansvarade för affärsprocesserna som detta system stödde. En IT-tjänsteman har också utsetts, ansvarig för den tekniska genomförandet av affärens behov i det specifika informationssystemet. De mest kritiska systemen för företaget och deras tekniska parametrar har dokumenterats, liksom tidsramar för införande och avveckling, med mera. Dessa parametrar har varit till stor hjälp i prepareringen av skapandet av rollmodellen.

Steg 3 Skapa metodologi

Nyckeln till framgång i alla projekt är en korrekt vald metod. Därför, både för skapandet av en rollmodell och för genomförandet av revisionen, behöver vi skapa en metodologi där vi beskriver samarbetet mellan avdelningar, bekräftar ansvar i företagets regler och så vidare.
För att börja måste vi undersöka alla existerande dokument som fastställer ordningen för att ge åtkomst och rättigheter. I princip bör processerna dokumenteras på flera nivåer:

• allmänna företagskrav;
• krav för informationssäkerhetsområden (beroende på verksamhetsområdena i organisationen);
• krav för tekniska processer (instruktioner, åtkomstmatriser, riktlinjer, krav på konfigurationer).

Inom vårt finansföretag upptäckte vi många föråldrade dokument – vi var tvungna att anpassa dem till de nya processer som implementerades.

På order av ledningen har en arbetsgrupp bildats som inkluderar representanter från säkerhet, IT, verksamhet och intern kontroll. I direktivet angavs målen för att skapa gruppen, inriktningen för arbetet, tidsramen och ansvariga från varje sida. Dessutom har vi utvecklat en metodik för att genomföra revisionen och ordningen för att bygga en rollmodell: dessa har godkänts av alla ansvariga representanter och bekräftats av företagets ledning.

Dokumenten som beskriver arbetsordningarna, tidsramar, ansvar, etc. – är en garanti för att ingen på vägen mot det eftersträvade målet, som från början inte är uppenbart för alla, kommer att ha frågor som “varför gör vi detta, varför behöver vi detta, etc.” och att det inte finns någon möjlighet att "hoppa av" eller bromsa processen.

Steg 4. Vi fastställer parametrarna för den befintliga åtkomsthanteringsmodellen

Vi skapar så kallat "systempass" för åtkomsthantering. I grunden är detta en enkät för ett specifikt informationssystem, där alla algoritmer för åtkomsthantering är dokumenterade. Företag som redan har implementerat IdM-lösningar är säkert bekanta med en sådan enkät, eftersom den utgör starten på systemforskningen.

En del av parametrarna om systemet och dess ägare har överförts till enkäten från IT-registret (se steg 2, revision), men nya har också tillkommit:

• hur hantering av konton utförs (direkt i databasen eller via programgränssnitt);
• hur användare loggar in i systemet (med en separat konto eller med användning av konto från AD, LDAP eller andra);
• vilka åtkomstnivåer som används i systemet (applikationsnivå, systemnivå, användning av nätverksresurser);
• beskrivning och parametrar servrar, som systemet arbetar med;
• vilka kontohanteringsoperationer som stöds (blockering, omdöpning, etc.);
• enligt vilka algoritmer eller regler användarens identifierare i systemet bildas;
• vilken attribut som kan kopplas till posten om en anställd i personalsystemet (namn, personalnummer eller andra);
• alla möjliga attribut för kontot och regler för deras ifyllnad;
• vilka åtkomsträttigheter som finns i systemet (roller, grupper, atomära rättigheter etc., om det finns inbäddade eller hierarkiska rättigheter);
• mekanismer för åtkomstkontroll (efter roller, avdelningar, funktioner osv.);
• finns det regler för åtskiljande av uppgifter i systemet (SOD – Segregation of Duties), och hur fungerar de;
• hur hanteras händelser av frånvaro, överflyttning, uppsägningar, datouppdateringar om anställda osv. i systemet?

Lista kan fortsätta med detaljer kring olika parametrar och andra objekt som är involverade i hanteringen av åtkomst.

Steg 5. Skapa en affärsinriktad beskrivning av befogenheter

Ytterligare ett dokument som vi behöver för att bygga en rollmodell är en katalog över alla möjliga befogenheter (rättigheter) som kan tilldelas användare i informationssystemet med en detaljerad beskrivning av den affärsfunktion som ligger bakom. Ofta är befogenheterna i systemet kodade med specifika benämningar bestående av bokstäver och siffror, och affärsanställda kan ha svårt att förstå vad dessa symboler står för. Då går de till IT-avdelningen, där de... också inte kan svara på frågor, exempelvis rörande sällan använda rättigheter. Då blir man tvungen att genomföra ytterligare tester.

Det är bra om den affärsinriktade beskrivningen redan finns eller till och med om dessa rättigheter har grupperats i grupper och roller. För vissa applikationer är det en bästa praxis att skapa en sådan katalog redan under utvecklingsfasen. Men detta förekommer sällan, så vi går återigen till IT-avdelningen för att samla information om alla möjliga rättigheter och beskriva dem. Vår katalog kommer slutligen att innehålla följande:

• benämning på befogenheten, inklusive objektet som åtkomsträtten gäller;
• åtgärden som tillåts att utföras med objektet (visning, ändring osv., möjlighet till begränsning, exempelvis efter geografiska kriterier eller kundgrupper);
• kod för befogenheten (kod och namn på funktion/systemförfrågan som kan utföras med befogenheten);
• beskrivning av befogenheten (detaljerad beskrivning av åtgärderna i IS vid tillämpning av befogenheten och dess konsekvenser för processen;
• status för befogenheten: "Aktiv" (om befogenheten har tilldelats minst en användare) eller "Inaktiv" (om befogenheten inte används).

Steg 6 Exportera data om användare och rättigheter från systemen och matcha med personalens källa.

I det sista steget av förberedelserna måste data från informationssystemen laddas ner om alla användare och de rättigheter de har för närvarande. Här är två möjliga scenarier. Först: säkerhetsavdelningen har direktåtkomst till systemet och har medel för att exportera relevanta rapporter, vilket är sällsynt men mycket bekvämt. För det andra: vi skickar en förfrågan till IT om att få rapporter i önskat format. Praktiken visar: det går sällan att förhandla med IT och få nödvändig information på första försöket. Man måste göra flera försök tills informationen är erhållen i rätt form och format.

Vilka data måste laddas ner:

• Användarnamn
• Anställds namn och efternamn knutna till det
• Status (aktiv eller blockerad)
• Datum för skapande av användarkonto
• Datum för senaste användning
• Lista över tillgängliga rättigheter/grupper/roller

Så, vi har fått nedladdningar från systemet med alla användare och alla rättigheter som de tilldelats. Vi har omedelbart lagt åt sidan alla blockerade konton, eftersom arbetet med att bygga rollenmodellen endast kommer att utföras för aktiva användare.

Sedan, om ditt företag inte har automatiserade verktyg för att stänga av åtkomst för uppsagda anställda (vilket är vanligt), eller om det finns en patchwork av automatisering som inte alltid fungerar korrekt, måste du identifiera alla "döda själar". Det handlar om konton för anställda som redan har sagt upp sig, vars rättigheter av någon anledning inte har blockerats – de behöver blockeras. För detta behöver vi matcha de nedladdade uppgifterna med personalresurskällan. Personalutmatningen måste också på förhand erhållas från avdelningen som hanterar personaldatabasen.

Det är viktigt att särskilja konton vars ägare inte har identifierats i personalregistret, dvs. för vilka ingen ansvarar — alltså övergivna konton. För den här listan behöver vi datum för senaste användning: om det är ganska aktuellt, måste vi ändå försöka hitta ägarna. Det kan handla om konton för externa entreprenörer eller tjänstekonton som inte är kopplade till någon specifik person, men som är relaterade till olika processer. För att klargöra ägarskapet för kontona kan vi skicka ut e-postmeddelanden till alla avdelningar med en begäran om svar. När ägarna har hittats, registrerar vi deras uppgifter i systemet: på så sätt blir alla aktiva konton identifierade, och övriga blockerar vi.

Så snart våra exportfiler har rensats från överflödiga poster och endast aktiva konton återstår kan vi börja bygga en rollmodell för det specifika informationssystemet. Men mer om det i nästa artikel.

Författare: Lyudmila Sevastyanova, marknadsföringschef på Solar inRights

Källa: habr.com