Vi bygger en rollbaserad modell för åtkomstkontroll. Del ett, förberedande

Jag arbetar för närvarande för en mjukvaruleverantör, speciellt lösningar för åtkomstkontroll. Och min erfarenhet "från ett tidigare liv" är kopplad till kundens sida - en stor finansiell organisation. På den tiden kunde vår passerkontrollgrupp på informationssäkerhetsavdelningen inte skryta med stora kompetenser inom IdM. Vi lärde oss mycket i processen, vi var tvungna att träffa många stötar för att bygga en fungerande mekanism för att hantera användarrättigheter i informationssystem i företaget.

Genom att kombinera min surt förvärvade kundupplevelse med leverantörens kunskap och kompetens, vill jag dela med mig av i huvudsak steg-för-steg-instruktioner: hur man skapar en rollbaserad åtkomstkontrollmodell i ett stort företag, och vad detta kommer att ge som ett resultat . Mina instruktioner består av två delar: den första förbereder sig för att bygga modellen, den andra bygger faktiskt. Här är den första delen, den förberedande delen.

NB Att bygga en förebild är tyvärr inte ett resultat, utan en process. Eller snarare, till och med en del av processen att skapa ett ekosystem för åtkomstkontroll i företaget. Så gör dig redo för spelet länge.

Låt oss först definiera det - vad är rollbaserad åtkomstkontroll? Anta att du har en stor bank med tiotals, eller till och med hundratusentals anställda (entiteter), som var och en har dussintals åtkomsträttigheter till hundratals interna bankinformationssystem (objekt). Multiplicera nu antalet objekt med antalet ämnen - detta är det minsta antalet anslutningar du behöver först bygga och sedan kontrollera. Är det verkligen möjligt att göra detta manuellt? Naturligtvis inte – roller skapades för att lösa detta problem.

En roll är en uppsättning behörigheter som en användare eller grupp av användare behöver för att utföra vissa 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 den rollen. Roller kan vara knutna till specifika befattningar, avdelningar eller funktionella uppgifter för anställda.

Roller skapas vanligtvis utifrån individuella medarbetarbehörigheter i varje informationssystem. Sedan bildas globala affärsroller utifrån rollerna för varje system. Till exempel kommer affärsrollen "kreditansvarig" att omfatta flera separata roller i de informationssystem som används på bankens kundkontor. Till exempel i det huvudsakliga automatiserade banksystemet, kontantmodulen, elektroniskt dokumenthanteringssystem, servicechef och andra. Affärsroller är som regel knutna till organisationsstrukturen - med andra ord till uppsättningen av företagsdivisioner och positioner i dem. Det är så en global rollmatris bildas (jag ger ett exempel i tabellen nedan).

Det är värt att notera att det helt enkelt är omöjligt att bygga en 100% förebild, som ger alla nödvändiga rättigheter för anställda i varje position i en kommersiell struktur. Ja, detta är inte nödvändigt. En förebild kan trots allt inte vara statisk, eftersom den beror på en ständigt föränderlig miljö. Och från förändringar i företagets affärsverksamhet, som följaktligen påverkar förändringar i organisationsstruktur och funktionalitet. Och från bristen på full tillgång till resurser och från bristande efterlevnad av arbetsbeskrivningar och från önskan om vinst på bekostnad av säkerheten och från många andra faktorer. Därför är det nödvändigt att bygga en förebild som kan täcka upp till 80 % av användarbehoven för de nödvändiga grundläggande rättigheterna när de tilldelas en tjänst. Och de kan, om det behövs, begära de återstående 20 % senare på separata ansökningar.

Naturligtvis kan du fråga: "Finns det inga 100% förebilder?" Tja, varför, detta händer till exempel i ideella strukturer som inte är föremål för frekventa förändringar - i något forskningsinstitut. Eller i militärindustriella komplexa organisationer med hög säkerhetsnivå, där säkerheten kommer i första hand. Det sker i en kommersiell struktur, men inom ramen för en separat division, vars arbete är en ganska statisk och förutsägbar process.

Den största fördelen med rollbaserad hantering är förenklingen av att utfärda rättigheter, eftersom antalet roller är betydligt mindre än antalet användare av informationssystemet. Och detta gäller för alla branscher.

Låt oss ta ett detaljhandelsföretag: det sysselsätter tusentals säljare, men de har samma uppsättning rättigheter i system N, och bara en roll kommer att skapas för dem. När en ny säljare kommer till företaget tilldelas han automatiskt den roll som krävs i systemet, som redan har alla nödvändiga befogenheter. Dessutom kan du med ett klick ändra rättigheterna för tusentals säljare samtidigt, till exempel lägga till ett nytt alternativ för att generera en rapport. Det finns ingen anledning att göra tusen operationer, länka en ny rättighet till varje konto - lägg bara till det här alternativet i rollen, så visas det för alla säljare samtidigt.

En annan fördel med rollbaserad hantering är elimineringen av utfärdandet av inkompatibla auktorisationer. Det vill säga att en anställd som har en viss roll i systemet inte samtidigt kan ha en annan roll, vars rättigheter inte ska kombineras med rättigheterna i den första. Ett slående exempel är förbudet mot att kombinera funktionerna input och kontroll av en finansiell transaktion.

Alla som är intresserade av hur rollbaserad passerkontroll kom till kan
dyka in i historien
Om vi ​​tittar på historien så tänkte IT-gemenskapen först på åtkomstkontrollmetoder redan på 70-talet av XNUMX-talet. Även om applikationer var ganska enkla då, precis som nu, ville alla verkligen hantera åtkomsten till dem bekvämt. Bevilja, ändra och kontrollera användarrättigheter - bara för att göra det lättare att förstå vilken åtkomst var och en av dem har. Men på den tiden fanns det inga gemensamma standarder, de första systemen för passerkontroll höll på att utvecklas och varje företag baserades på sina egna idéer och regler.

Många olika passerkontrollmodeller är nu kända, men de dök inte upp direkt. Låt oss uppehålla oss vid dem som har gjort ett betydande bidrag till utvecklingen av detta område.

Den första och förmodligen den enklaste modellen är Diskretionär (selektiv) åtkomstkontroll (DAC – Discretionary access control). Denna modell innebär att alla deltagare i åtkomstprocessen delar rättigheter. Varje användare har tillgång till specifika objekt eller operationer. I huvudsak motsvarar här uppsättningen av subjekt av rättigheter mängden objekt. Denna modell visade sig vara för flexibel och för svår att underhålla: åtkomstlistor blir så småningom enorma och svåra att kontrollera.

Den andra modellen är Obligatorisk åtkomstkontroll (MAC - Obligatorisk åtkomstkontroll). Enligt denna modell får varje användare tillgång till ett objekt i enlighet med den utfärdade åtkomsten till en viss nivå av datakonfidentialitet. Följaktligen bör föremål kategoriseras efter deras sekretessnivå. Till skillnad från den första flexibla modellen visade sig den här tvärtom vara för strikt och restriktiv. Dess användning är inte motiverad när företaget har många olika informationsresurser: för att skilja åtkomsten till olika resurser måste du införa många kategorier som inte kommer att överlappa varandra.

På grund av de uppenbara bristerna i dessa två metoder har IT-gemenskapen fortsatt att utveckla modeller som är mer flexibla och samtidigt mer eller mindre universella för att stödja olika typer av organisatoriska åtkomstkontrollpolicyer. Och så dök det upp den tredje rollbaserade åtkomstkontrollmodellen! Detta tillvägagångssätt har visat sig vara det mest lovande eftersom det inte bara kräver auktorisering av användarens identitet, utan även hans operativa funktioner i systemen.

Den första tydligt beskrivna förebildsstrukturen föreslogs av de amerikanska forskarna David Ferrailo och Richard Kuhn från US National Institute of Standards and Technology 1992. Då dök termen först upp RBAC (Rollbaserad åtkomstkontroll). Dessa studier och beskrivningar av huvudkomponenterna, såväl som deras relationer, utgjorde grunden för INCITS 359-2012-standarden, som fortfarande är i kraft idag, godkänd av International Committee on Information Technology Standards (INCITS).

Standarden definierar en roll som "en jobbfunktion inom ramen för en organisation med viss tillhörande semantik angående den auktoritet och det ansvar som tilldelas användaren som tilldelats rollen." Dokumentet fastställer de grundläggande delarna av RBAC - användare, sessioner, roller, behörigheter, operationer och objekt, såväl som relationerna och sammankopplingarna mellan dem.

Standarden tillhandahåller den minsta nödvändiga strukturen för att bygga en rollmodell - kombinera rättigheter till roller och sedan ge åtkomst till användare genom dessa roller. Mekanismerna för att komponera roller från objekt och operationer beskrivs, rollhierarkin och befogenheters arv beskrivs. När allt kommer omkring, i alla företag finns det roller som kombinerar grundläggande befogenheter som är nödvändiga för alla anställda i företaget. Detta kan vara tillgång till e-post, EDMS, företagsportal, etc. Dessa behörigheter kan inkluderas i en allmän roll som kallas "anställd", och det finns inget behov av att lista alla grundläggande rättigheter om och om igen i var och en av rollerna på högre nivå. Det räcker att helt enkelt ange arvsegenskapen för rollen "anställd".

Senare kompletterades standarden med nya åtkomstattribut relaterade till den ständigt föränderliga miljön. Möjligheten att införa statiska och dynamiska begränsningar har lagts till. Statiska innebär omöjligheten att kombinera roller (samma input och kontroll av operationer som nämnts ovan). Dynamiska begränsningar kan bestämmas genom att ändra parametrar, till exempel tid (arbetstid/fri arbetstid eller dagar), plats (kontor/hem) etc.

Det är värt att nämna separat attributbaserad åtkomstkontroll (ABAC - Attributbaserad åtkomstkontroll). Tillvägagångssättet bygger på att ge åtkomst med hjälp av regler för attributdelning. Denna modell kan användas separat, men ganska ofta kompletterar den aktivt den klassiska förebilden: attribut för användare, resurser och enheter, såväl som tid eller plats, kan läggas till en viss roll. Detta gör att du kan använda färre roller, införa ytterligare begränsningar och göra åtkomsten så minimal som möjligt och därför förbättra säkerheten.

En revisor kan till exempel få tillgång till konton om han arbetar i en viss region. Sedan jämförs specialistens plats med ett visst referensvärde. Eller så kan du bara ge åtkomst till konton om användaren loggar in från en enhet som ingår i listan över tillåtna. Ett bra komplement till en förebild, men används sällan på egen hand på grund av behovet av att skapa många regler och tabeller över behörigheter eller begränsningar.

Låt mig ge dig ett exempel på hur jag använder ABAC från mitt "tidigare liv". Vår bank hade flera kontor. Anställda på kundkontor i dessa filialer utförde exakt samma operationer, men var tvungna att arbeta i huvudsystemet endast med konton i sin region. Först började vi skapa separata roller för varje region - och det fanns så många sådana roller med repeterande funktionalitet, men med tillgång till olika konton! Sedan, genom att använda ett platsattribut för användaren och associera det med ett specifikt antal konton att granska, minskade vi antalet roller i systemet avsevärt. Som ett resultat återstod roller för endast en filial, som replikerades för motsvarande positioner i alla andra territoriella divisioner av banken.

Låt oss nu prata om de nödvändiga förberedande stegen, utan vilka det helt enkelt är omöjligt att bygga en fungerande förebild.

Steg 1. Skapa en funktionell modell

Du bör börja med att skapa en funktionell modell – ett dokument på toppnivå som i detalj beskriver funktionaliteten för varje avdelning och varje tjänst. Som regel kommer information in från olika dokument: arbetsbeskrivningar och regler för enskilda enheter - avdelningar, avdelningar, avdelningar. Funktionsmodellen ska överenskommas med alla intresserade avdelningar (affär, intern kontroll, säkerhet) och godkännas av företagets ledning. Vad är detta dokument till för? Så att förebilden kan referera till det. Till exempel ska du bygga en förebild baserad på anställdas befintliga rättigheter - lossad från systemet och "reducerad till en gemensam nämnare". När man sedan kommer överens om de mottagna rollerna med systemets företagare kan man hänvisa till en specifik punkt i funktionsmodellen, utifrån vilken den eller den rättigheten ingår i rollen.

Steg 2. Vi granskar IT-system och gör en prioriteringsplan

I det andra steget bör du göra en revision av IT-system för att förstå hur tillgången till dem är organiserad. Mitt finansbolag drev till exempel flera hundra informationssystem. Alla system hade några rudiment av rollbaserad hantering, de flesta hade vissa roller, men mestadels på papper eller i systemkatalogen - de var länge föråldrade och åtkomst till dem beviljades baserat på faktiska användarförfrågningar. Naturligtvis är det helt enkelt omöjligt att bygga en förebild i flera hundra system samtidigt, man måste börja någonstans. Vi genomförde en djupgående analys av åtkomstkontrollprocessen för att fastställa dess mognadsnivå. Under analysprocessen utvecklades kriterier för prioritering av informationssystem – kritikalitet, beredskap, planer för avveckling m.m. Med deras hjälp radade vi upp utveckling/uppdatering av förebilder för dessa system. Och så inkluderade vi förebilder i planen för integration med Identity Management-lösningen för att automatisera passerkontroll.

Så hur avgör man hur kritiskt ett system är? Svara själv på följande frågor:

• Är systemet kopplat till de operativa processer som företagets kärnverksamhet är beroende av?
• Kommer systemavbrott att påverka integriteten hos företagets tillgångar?
• Vad är den maximala tillåtna driftstopptiden för systemet, när det är omöjligt att återställa aktiviteten efter ett avbrott?
• Kan en kränkning av informationens integritet i systemet leda till oåterkalleliga konsekvenser, både ekonomiska och anseende?
• Kritik mot bedrägerier. Förekomsten av funktionalitet, om den inte kontrolleras korrekt, kan leda till interna/externa bedrägliga åtgärder;
• Vilka är de juridiska kraven och interna regler och procedurer för dessa system? Kommer det att bli böter från tillsynsmyndigheter för bristande efterlevnad?

I vårt finansbolag gjorde vi en sådan här revision. Ledningen utvecklade granskningsförfarandet för åtkomsträttigheter för att först titta på befintliga användare och rättigheter i de informationssystem som stod på den högsta prioritetslistan. Säkerhetsavdelningen tilldelades som ägare av denna process. Men för att få en helhetsbild av åtkomsträttigheterna i företaget var det nödvändigt att involvera IT- och affärsavdelningar i processen. Och här började tvister, missförstånd och ibland till och med sabotage: ingen vill bryta sig loss från sitt nuvarande ansvar och engagera sig i några, vid första anblicken, obegripliga aktiviteter.

NB Stora företag med utvecklade IT-processer är förmodligen bekanta med IT-revisionsproceduren - IT General Controls (ITGC), som låter dig identifiera brister i IT-processer och etablera kontroll för att förbättra processer i enlighet med bästa praxis (ITIL, COBIT, IT) Styrning etc.) En sådan revision tillåter IT och verksamhet att bättre förstå varandra och utveckla en gemensam utvecklingsstrategi, analysera risker, optimera kostnader och utveckla effektivare arbetssätt.



Ett av revisionsområdena är att fastställa parametrarna för logisk och fysisk åtkomst till informationssystem. Vi tog de erhållna uppgifterna som underlag för vidare användning för att bygga en förebild. Som ett resultat av denna granskning hade vi ett register över IT-system, där deras tekniska parametrar fastställdes och beskrivningar gavs. Dessutom identifierades för varje system en ägare från den affärsriktning i vars intresse det drevs: det var han som var ansvarig för de affärsprocesser som detta system tjänade. En IT-servicechef utsågs också, ansvarig för den tekniska implementeringen av affärsbehov för en specifik IS. De mest kritiska systemen för företaget och deras tekniska parametrar, villkor för driftsättning och avveckling etc. Dessa parametrar var till stor hjälp i förberedelserna inför skapandet av en förebild.

Steg 3 Skapa en metodik

Nyckeln till framgång för alla företag är rätt metod. Därför behöver vi både för att bygga en förebild och för att genomföra en revision skapa en metodik där vi beskriver samspelet mellan avdelningar, etablerar ansvar i företagets regelverk etc.
Först måste du granska alla tillgängliga dokument som fastställer förfarandet för att bevilja tillgång och rättigheter. På ett bra sätt bör processer dokumenteras på flera nivåer:

• allmänna företagskrav;
• krav på informationssäkerhetsområden (beroende på områdena för organisationens verksamhet);
• krav på tekniska processer (instruktioner, åtkomstmatriser, riktlinjer, konfigurationskrav).

I vårt finansiella företag hittade vi många föråldrade dokument, vi var tvungna att ta dem i enlighet med de nya processer som implementerades.

I ledningsföreställning skapades en arbetsgrupp som innehöll representanter från säkerhet, IT, verksamhet och intern kontroll. I ordningen skisserades målen för att skapa gruppen, verksamhetens inriktning, existensperioden och ansvariga från varje sida. Dessutom utvecklade vi en revisionsmetodik och en procedur för att konstruera en förebild: de godkändes av alla ansvariga representanter för områdena och godkändes av företagets ledning.

Handlingar som beskriver tillvägagångssätt för att utföra arbete, tidsfrister, ansvar m.m. - en garanti för att på vägen mot det omhuldade målet, som till en början inte är självklart för alla, kommer ingen att ha frågor "varför gör vi det här, varför behöver vi det, etc." och det kommer inte att finnas någon möjlighet att "hoppa av" eller sakta ner processen.

Steg 4. Fixa parametrarna för den befintliga åtkomstkontrollmodellen

Vi håller på att upprätta ett så kallat ”systempass” vad gäller passerkontroll. I huvudsak är detta ett frågeformulär om ett specifikt informationssystem, som registrerar alla algoritmer för att kontrollera åtkomsten till det. Företag som redan implementerat lösningar av IdM-klass känner förmodligen till ett sådant frågeformulär, eftersom det är här som forskningen av system börjar.

Några parametrar om systemet och ägare flödade in i frågeformuläret från IT-registret (se steg 2, revision), men nya tillkom också:

• hur konton hanteras (direkt i databasen eller via mjukvarugränssnitt);
• hur användare loggar in på systemet (med ett separat konto eller med ett AD-konto, LDAP, etc.);
• vilka nivåer av åtkomst till systemet som används (applikationsnivå, systemnivå, systemanvändning av nätverksfilresurser);
• beskrivning och parametrar för de servrar som systemet körs på;
• vilka kontohanteringsoperationer som stöds (blockering, byte av namn, etc.);
• vilka algoritmer eller regler som används för att generera systemets användaridentifierare;
• vilket attribut kan användas för att upprätta en koppling till en anställds register i personalsystemet (fullständigt namn, personalnummer, etc.);
• alla möjliga kontoattribut och regler för att fylla i dem;
• vilka åtkomsträttigheter som finns i systemet (roller, grupper, atomrättigheter, etc., finns det kapslade eller hierarkiska rättigheter);
• mekanismer för uppdelning av åtkomsträttigheter (efter position, avdelning, funktionalitet etc.);
• Har systemet regler för segregering av rättigheter (SOD – Segregation of Duties), och hur fungerar de;
• hur händelser av frånvaro, överlåtelse, uppsägning, uppdatering av personaluppgifter etc. behandlas i systemet.

Denna lista kan fortsätta med detaljer om de olika parametrarna och andra objekt som är involverade i åtkomstkontrollprocessen.

Steg 5. Skapa en affärsorienterad beskrivning av behörigheter

Ett annat dokument som vi kommer att behöva när vi bygger en förebild är en uppslagsbok om alla möjliga befogenheter (rättigheter) som kan ges till användare i informationssystemet med en detaljerad beskrivning av den verksamhetsfunktion som står bakom. Ofta är myndigheter i systemet krypterade med vissa namn som består av bokstäver och siffror, och företagsanställda kan inte lista ut vad som ligger bakom dessa symboler. Sedan går de till IT-tjänsten, och där... kan de inte heller svara på frågan om till exempel sällan använda rättigheter. Sedan måste ytterligare tester göras.

Det är bra om det redan finns en verksamhetsbeskrivning eller till och med om det finns en kombination av dessa rättigheter i grupper och roller. För vissa applikationer är bästa praxis att skapa en sådan referens i utvecklingsstadiet. Men detta händer inte ofta, så vi går igen till IT-avdelningen för att samla information om alla möjliga rättigheter och beskriva dem. Vår guide kommer i slutändan att innehålla följande:

• myndighetens namn, inklusive det föremål som tillträdesrätten gäller;
• en åtgärd som är tillåten att göra med ett objekt (visa, ändra, etc., möjligheten till begränsning, till exempel på territoriell grund eller efter grupp av klienter);
• auktoriseringskod (kod och namn på systemfunktionen/begäran som kan utföras med auktoriseringen);
• beskrivning av myndigheten (detaljerad beskrivning av åtgärder i IS vid tillämpning av myndigheten och deras konsekvenser för processen;
• behörighetsstatus: "Aktiv" (om behörigheten är tilldelad till minst en användare) eller "Inte aktiv" (om behörigheten inte används).

Steg 6 Vi laddar ner data om användare och rättigheter från systemen och jämför dem med personalkällan

I slutskedet av förberedelsen måste du ladda ner data från informationssystem om alla användare och de rättigheter som de har för närvarande. Det finns två möjliga scenarier här. För det första: säkerhetsavdelningen har direkt tillgång till systemet och har möjlighet att ladda ner relevanta rapporter, vilket inte händer ofta, men är väldigt bekvämt. För det andra: vi skickar en begäran till IT om att få rapporter i det format som krävs. Erfarenheten visar att det inte går att komma överens med IT och få nödvändiga uppgifter första gången. Det är nödvändigt att göra flera tillvägagångssätt tills informationen tas emot i önskad form och format.

Vilken data behöver laddas ner:

• Kontonamn
• Fullständigt namn på den anställde som det är tilldelat
• Status (aktiv eller blockerad)
• Datum för att skapa konto
• Datum för senaste användning
• Lista över tillgängliga rättigheter/grupper/roller

Så vi fick nedladdningar från systemet med alla användare och alla rättigheter som tilldelades dem. Och de lägger omedelbart åt sidan alla blockerade konton, eftersom arbetet med att bygga en förebild endast kommer att utföras för aktiva användare.

Sedan, om ditt företag inte har automatiserade sätt att blockera åtkomst till avskedade anställda (detta händer ofta) eller har lapptäckeautomatisering som inte alltid fungerar korrekt, måste du identifiera alla "döda själar." Vi pratar om konton för anställda som redan har fått sparken, vars rättigheter inte är blockerade av någon anledning - de måste blockeras. För att göra detta jämför vi den uppladdade informationen med personalkällan. Personalavlastning ska också erhållas i förväg från den avdelning som underhåller personaldatabasen.

Separat är det nödvändigt att avsätta konton vars ägare inte hittades i personaldatabasen, inte tilldelade någon - det vill säga ägarelösa. Med den här listan behöver vi datumet för senaste användning: om det är ganska nyligen måste vi fortfarande leta efter ägarna. Detta kan inkludera konton för externa entreprenörer eller tjänstekonton som inte är tilldelade någon, men som är kopplade till eventuella processer. För att ta reda på vem kontona tillhör kan du skicka brev till alla avdelningar och be dem svara. När ägarna hittas anger vi data om dem i systemet: på så sätt identifieras alla aktiva konton och resten blockeras.

Så fort våra uppladdningar är rensade från onödiga register och endast aktiva konton finns kvar, kan vi börja bygga en förebild för ett specifikt informationssystem. Men jag kommer att berätta om detta i nästa artikel.

Författare: Lyudmila Sevastyanova, marknadsföringsansvarig Solar inRights

Källa: will.com