Nu arbejder jeg for en softwareleverandør, især adgangskontrolløsninger. Og min erfaring "fra et tidligere liv" hænger sammen med kundesiden - en stor finansiel institution. På det tidspunkt kunne vores adgangskontrolgruppe i informationssikkerhedsafdelingen ikke prale af store kompetencer inden for IdM. Vi lærte meget i processen, vi var nødt til at udfylde en bunke bump for at bygge en fungerende mekanisme til at administrere brugerrettigheder i informationssystemer i virksomheden.
Ved at kombinere min erfaring fra kunden med leverandørviden og -kompetencer, vil jeg i det væsentlige dele en trin-for-trin instruktion med dig: hvordan man opretter en rollebaseret adgangskontrolmodel i en stor virksomhed, og hvad den vil give i ende. Min instruktion består af to dele: den første - vi forbereder os på at bygge en model, den anden - vi bygger den faktisk. Før du del et, forberedende.
NB Opbygning af en rollemodel er desværre ikke et resultat, men en proces. Eller rettere sagt en del af processen med at skabe et adgangskontroløkosystem i virksomheden. Så tuner ind på spillet i lang tid.
Lad os først definere - hvad er rollebaseret adgangskontrol? Antag, at du har en stor bank med titusinder eller endda hundredtusindvis af ansatte (subjekter), som hver især har snesevis af adgangsrettigheder til hundredvis af intra-bank informationssystemer (objekter). Og gang nu antallet af objekter med antallet af emner - det er hvor mange forbindelser du i det mindste skal bygge først og derefter kontrollere. Er det virkelig muligt at gøre det manuelt? Selvfølgelig ikke - roller syntes at løse dette problem.
En rolle er et sæt tilladelser, som en bruger eller gruppe af brugere har brug for for at udføre bestemte arbejdsopgaver. Hver medarbejder kan have en eller flere roller, og hver rolle kan indeholde en til mange tilladelser, som er tilladt for en bruger i den pågældende rolle. Roller kan være knyttet til bestemte stillinger, afdelinger eller funktionelle opgaver for medarbejdere.
Roller oprettes normalt ud fra individuelle medarbejderautorisationer i hvert informationssystem. Derefter dannes globale forretningsroller ud fra rollerne for hvert system. Eksempelvis vil erhvervsrollen "låneansvarlig" omfatte flere separate roller i informationssystemer, der anvendes på bankens kundekontor. For eksempel i det primære automatiserede banksystem, kasseapparat, elektronisk dokumenthåndteringssystem, service manager og andre. Forretningsroller er som regel bundet til den organisatoriske struktur - med andre ord til et sæt virksomhedsafdelinger og stillinger i dem. Sådan er den globale rollematrix dannet (jeg giver et eksempel i tabellen nedenfor).
Det er værd at bemærke, at det simpelthen er umuligt at opbygge en 100% rollemodel, der giver alle de nødvendige rettigheder til medarbejdere i hver stilling i en kommerciel struktur. Ja, det er ikke nødvendigt. Rollemodellen kan jo ikke være statisk, fordi den afhænger af de konstant skiftende omgivelser. Og fra en ændring i virksomhedens forretningsaktiviteter, som følgelig påvirker ændringen i den organisatoriske struktur og funktionalitet. Og fra manglen på fuld tilførsel af ressourcer og fra manglende overholdelse af jobbeskrivelser og fra ønsket om profit på bekostning af sikkerhed og fra mange andre faktorer. Derfor er det nødvendigt at opbygge en rollemodel, der kan dække op til 80 % af brugernes behov for de nødvendige basale rettigheder, når de bliver ansat i en stilling. Og de resterende 20% vil de om nødvendigt være i stand til at forhøre senere på separate applikationer.
Selvfølgelig kan du spørge: "Hvad, der er ingen 100% rollemodeller overhovedet?" Nå, hvorfor, dette sker for eksempel i non-profit strukturer, der ikke er genstand for hyppige ændringer - i nogle forskningsinstitutter. Eller i militærindustrielle komplekse organisationer med et højt sikkerhedsniveau, hvor sikkerhed kommer i første række. Det sker, og det i en kommerciel struktur, men inden for rammerne af en enkelt enhed, hvis arbejde er en ret statisk og forudsigelig proces.
Den største fordel ved rollebaseret ledelse er forenklingen af udstedelsen af rettigheder, fordi antallet af roller er væsentligt mindre end antallet af brugere af informationssystemet. Og det gælder for enhver branche.
Lad os tage en detailvirksomhed: den beskæftiger tusindvis af sælgere, men de har det samme sæt rettigheder i N-systemet, og der vil kun blive oprettet én rolle for dem. En ny sælger kom til virksomheden - han blev automatisk tildelt den nødvendige rolle i systemet, som allerede har alle de nødvendige beføjelser. Med et enkelt klik kan du også ændre rettighederne for tusindvis af sælgere på én gang, for eksempel tilføje en ny mulighed for at generere en rapport. Du behøver ikke at udføre tusinde operationer, der knytter en ny rettighed til hver konto - bare føj denne mulighed til rollen, og den vises for alle sælgere på samme tid.
En anden fordel ved rollebaseret administration er undgåelsen af inkompatible tilladelser. Det vil sige, at en medarbejder, der har en bestemt rolle i systemet, ikke samtidig kan have en anden rolle, hvis rettigheder ikke skal kombineres med rettighederne i den første. Et levende eksempel er forbuddet mod at kombinere funktionerne input og kontrol af en finansiel transaktion.
Det kan enhver, der er interesseret i, hvordan rollebaseret adgangskontrol opstod i første omgang
dykke ned i historien
Hvis vi vender os til historien, så tænkte IT-samfundet for første gang på adgangskontrolmetoder tilbage i 70'erne af det XX århundrede. Selvom applikationer dengang var ret enkle, men som nu ville alle virkelig nemt administrere adgangen til dem. Giv, ændr og kontroller brugerrettigheder - bare for at gøre det nemmere at forstå, hvilken adgang hver af dem har. Men på det tidspunkt var der ingen fælles standarder, de første adgangskontrolsystemer var under udvikling, og hver virksomhed var baseret på sine egne ideer og regler.
Mange forskellige adgangskontrolmodeller kendes nu, men de dukkede ikke op med det samme. Lad os dvæle ved dem, der har ydet et håndgribeligt bidrag til udviklingen af denne retning.
Den første og nok den enkleste model er Skønsmæssig (selektiv) adgangskontrol (DAC - Diskretionær adgangskontrol). Denne model indebærer, at alle deltagere i adgangsprocessen deler rettigheder. Hver bruger får adgang til specifikke objekter eller operationer. Faktisk svarer sættet af subjekter af rettigheder her til sættet af objekter. Denne model viste sig at være for fleksibel og for svær at vedligeholde: adgangslister bliver enorme og svære at kontrollere over tid.
Den anden model er Obligatorisk adgangskontrol (MAC). Ifølge denne model får hver bruger adgang til objektet i overensstemmelse med den udstedte adgang til et bestemt niveau af datafortrolighed. I overensstemmelse hermed bør objekter kategoriseres efter fortrolighedsniveauet. I modsætning til den første fleksible model viste denne sig tværtimod at være for streng og restriktiv. Dets brug retfærdiggør ikke sig selv, når virksomheden har en masse forskellige informationsressourcer: For at afgrænse adgangen til forskellige ressourcer, bliver du nødt til at indføre mange kategorier, der ikke vil overlappe hinanden.
På grund af de åbenlyse ufuldkommenheder ved disse to metoder, har it-samfundet fortsat med at udvikle modeller, der er mere fleksible og samtidig mere eller mindre universelle til at understøtte forskellige typer af organisatoriske adgangskontrolpolitikker. Og det var da det dukkede op den tredje model for rollebaseret adgangskontrol! Denne tilgang viste sig at være den mest lovende, da den ikke kun kræver autorisation af brugerens identitet, men også hans arbejdsfunktioner i systemerne.
Den første velbeskrevne rollemodelstruktur blev foreslået af amerikanske videnskabsmænd David Ferrailo og Richard Kuhn fra US National Institute of Standards and Technology i 1992. Så dukkede udtrykket først op RBAC (Rollebaseret adgangskontrol). Disse undersøgelser og beskrivelser af hovedkomponenterne, samt deres relationer, dannede grundlaget for INCITS 359-2012 standarden, som er gyldig til i dag, godkendt af International Committee for Information Technology Standards (INCITS).
Standarden definerer en rolle som "en jobfunktion i en organisations kontekst med noget tilhørende semantik vedrørende den autoritet og det ansvar, der er tildelt den bruger, der er tildelt rollen". Dokumentet etablerer de grundlæggende elementer i RBAC - brugere, sessioner, roller, tilladelser, operationer og objekter, såvel som relationerne og relationerne mellem dem.
Standarden giver den mindst nødvendige struktur til at opbygge en rollemodel - kombinerer rettigheder i roller og giver derefter adgang til brugere gennem disse roller. Mekanismerne til at sammensætte roller ud fra objekter og operationer er skitseret, rollernes hierarki og nedarvningen af beføjelser er beskrevet. Faktisk er der i enhver virksomhed roller, der kombinerer elementære beføjelser, som er nødvendige for alle virksomhedens ansatte. Dette kan være adgang til e-mail, til EDMS, til virksomhedsportalen mv. Disse tilladelser kan inkluderes i én generel rolle kaldet "medarbejder", og det vil ikke være nødvendigt i hver af rollerne på højere niveau at liste alle de elementære rettigheder igen og igen. Det er nok bare at angive tegnet på arv af "medarbejder"-rollen.
Senere blev standarden suppleret med nye adgangsattributter relateret til det stadigt skiftende miljø. Tilføjet muligheden for at indføre statiske og dynamiske begrænsninger. Statiske indebærer umuligheden af at kombinere roller (samme input og kontrol af operationer som nævnt ovenfor). Dynamiske grænser kan defineres ved at ændre parametre som f.eks. tid (arbejds-/ikke-arbejdstid eller dage), lokation (kontor/hjem) og lignende.
Separat skal det siges om Attribut-baseret adgangskontrol (ABAC). Fremgangsmåden er baseret på at give adgang ved hjælp af regler for attributdeling. Denne model kan bruges separat, men ganske ofte supplerer den aktivt den klassiske rollemodel: du kan tilføje attributter for brugere, ressourcer og enheder samt tid eller sted til en specifik rolle. Dette giver dig mulighed for at bruge færre roller, indføre yderligere begrænsninger og gøre adgangen minimal nok, og dermed øge sikkerheden.
For eksempel kan en revisor få adgang til konti, hvis han arbejder i en bestemt region. Derefter vil specialistens placering blive sammenlignet med en vis referenceværdi. Eller du kan kun give adgang til konti, hvis brugeren logger på fra en enhed, der er indtastet i registret over tilladte. En god tilføjelse til rollemodellen, men bruges sjældent alene på grund af behovet for at lave mange regler og tabeller over tilladelser eller begrænsninger.
Jeg vil give et eksempel på brugen af ABAC fra mit "tidligere liv". Vores bank havde flere filialer. Medarbejdere på kundekontorer i disse filialer udførte nøjagtig de samme operationer, men skulle kun arbejde i hovedsystemet med konti i deres region. Først begyndte vi at oprette separate roller for hver region - og der var så mange sådanne roller med gentagende funktionalitet, men med adgang til forskellige konti! Derefter reducerede vi antallet af roller i systemet betydeligt ved at bruge en lokationsattribut for en bruger og linke den til en bestemt række konti for at kontrollere. Som et resultat forblev roller kun for én filial, som blev replikeret til de tilsvarende stillinger i alle andre territoriale afdelinger af banken.
Og lad os nu tale om de nødvendige forberedende trin, uden hvilke det simpelthen er umuligt at opbygge en fungerende rollemodel.
Trin 1. Opret en funktionel model
Det er værd at starte med oprettelsen af en funktionel model - et dokument på øverste niveau, der detaljeret beskriver funktionaliteten af hver enhed og hver position. Som regel indtastes oplysninger fra forskellige dokumenter: jobbeskrivelser og regler for individuelle afdelinger - afdelinger, afdelinger, afdelinger. Funktionsmodellen skal aftales med alle interesserede afdelinger (forretning, intern kontrol, sikkerhed) og godkendes af virksomhedens ledelse. Hvad er dette dokument til? Så forbilledet kan henvise til det. For eksempel skal du bygge en rollemodel baseret på medarbejdernes eksisterende rettigheder - losset fra systemet og "reduceret til en fællesnævner". Så kan man, når man aftaler de modtagne roller med virksomhedsejeren af systemet, henvise til et specifikt element i funktionsmodellen, på grundlag af hvilket denne eller hin ret er inkluderet i rollen.
Trin 2. Vi reviderer IT-systemer og laver en prioriteringsplan
På anden fase bør der foretages en revision af it-systemer for at forstå, hvordan adgangen til dem er organiseret. For eksempel drev mit finansielle firma flere hundrede informationssystemer. I alle systemer var der nogle rudimenter af rollestyring, i de fleste - nogle roller, men mest på papiret eller i systemkataloget - er de for længst forældede, og adgangen til dem blev distribueret efter de faktiske brugeranmodninger. Det er naturligvis ganske enkelt umuligt at bygge en rollemodel i flere hundrede systemer på én gang, man skal starte et sted. Vi gennemførte en dybdegående analyse af adgangskontrolprocessen for at bestemme dens modenhedsniveau. I analyseprocessen blev der udviklet kriterier for prioritering af informationssystemer - kritikalitet, beredskab, planer for nedlukning mv. Med deres hjælp byggede vi en sekvens for udvikling/opdatering af rollemodeller for disse systemer. Og så - inkluderet rollemodeller i planen for integration med Identity Management-løsningen for at automatisere adgangskontrol.
Så hvordan bestemmer man systemets kritikalitet? Besvar dig selv på følgende spørgsmål:
- Er systemet knyttet til de operationelle processer, som virksomhedens kerneforretning afhænger af?
- Vil afbrydelsen af systemet påvirke integriteten af virksomhedens aktiver?
- Hvad er den maksimalt tilladte nedetid for systemet, hvorefter det er umuligt at genoprette aktiviteten efter en afbrydelse?
- Kan en krænkelse af integriteten af informationer i systemet føre til irreversible konsekvenser, både økonomiske og omdømmemæssige?
- Kritik af svindel. Tilstedeværelsen af funktionalitet, med utilstrækkelig kontrol, som det er muligt at udføre interne / eksterne svigagtige handlinger;
- Hvad er de juridiske krav samt interne regler og procedurer for disse systemer? Vil der være bøder fra tilsynsmyndigheder for manglende overholdelse?
I vores finansielle virksomhed gennemførte vi en revision som denne. Ledelsen har udviklet en revisionsprocedure for adgangsrettigheder til at behandle eksisterende brugere og rettigheder først på de informationssystemer, der er på topprioritetslisten. Sikkerhedsafdelingen er blevet tildelt ejeren af denne proces. Men for at få et samlet billede af adgangsrettighederne i virksomheden var det nødvendigt at inddrage IT- og forretningsafdelinger i processen. Og her begyndte tvister, misforståelser og nogle gange endda sabotage: ingen ønsker at bryde væk fra deres nuværende pligter og blive involveret i nogle, ved første øjekast, uforståelige aktiviteter.
NB Store virksomheder med udviklede IT-processer kender formentlig til IT-revisionsproceduren - IT General Controls (ITGC), som giver dig mulighed for at identificere mangler i IT-processer og etablere kontrol for at forbedre processer i overensstemmelse med best practice (ITIL, COBIT, IT) Governance etc.) En sådan revision giver IT og forretning mulighed for bedre at forstå hinanden og udvikle en fælles udviklingsstrategi, analysere risici, optimere omkostninger og udvikle mere effektive tilgange til arbejdet.
Et af revisionsområderne er at bestemme parametrene for logisk og fysisk adgang til informationssystemer. Vi tog de indhentede data som grundlag for videre brug i opbygningen af en rollemodel. Som følge af en sådan revision har vi et register over it-systemer, hvori deres tekniske parametre er fastlagt og beskrevet. Derudover blev der for hvert system bestemt en ejer ud fra den forretningsretning, i hvis interesser det blev drevet: det var ham, der var ansvarlig for de forretningsprocesser, som dette system tjente. Der blev også udpeget en IT-servicechef, ansvarlig for den tekniske implementering af forretningsbehov i en specifik IS. Der blev registreret de mest kritiske systemer for virksomheden og deres tekniske parametre, idriftsættelses- og nedlukningsdatoer osv. Disse parametre hjalp meget i processen med at forberede opbygningen af en rollemodel.
Trin 3 Opret en metode
Nøglen til succes for enhver virksomhed er den rigtige metode. Derfor er vi både for at opbygge en rollemodel og for at gennemføre en revision nødt til at skabe en metodik, hvor vi vil beskrive samspillet mellem afdelinger, fastlægge ansvar i virksomhedens regler mv.
Først skal du undersøge alle de tilgængelige dokumenter, der fastlægger proceduren for at give adgang og rettigheder. På en god måde bør processer dokumenteres på flere niveauer:
- generelle virksomhedskrav;
- krav til områderne informationssikkerhed (afhænger af organisationens aktiviteter);
- krav til teknologiske processer (instruktioner, adgangsmatricer, retningslinjer, konfigurationskrav).
I vores finansielle virksomhed fandt vi en masse forældede dokumenter - vi skulle bringe dem i overensstemmelse med de nye processer, der blev indført.
Efter ordre fra ledelsen blev der nedsat en arbejdsgruppe, som omfattede repræsentanter fra områderne sikkerhed, IT, forretning og intern kontrol. Ordren skitserede målene med at skabe gruppen, aktivitetsretningen, eksistensperioden og hver sides ansvar. Derudover har vi udviklet en revisionsmetodologi og en procedure for opbygning af en rollemodel: De blev vedtaget af alle ansvarlige repræsentanter for områderne og godkendt af virksomhedens ledelse.
Dokumenter, der beskriver proceduren for udførelse af arbejde, tidsfrister, ansvar mv. - en garanti for, at på vej mod det elskede mål, som i første omgang ikke er indlysende for alle, vil ingen have spørgsmål "hvorfor gør vi det her, hvorfor har vi brug for det osv." og der vil ikke være mulighed for at "springe af" eller bremse processen.
Trin 4. Fastsættelse af parametrene for den eksisterende adgangskontrolmodel
Vi udarbejder det såkaldte "systempas" med hensyn til adgangskontrol. Faktisk er der tale om et spørgeskema om et specifikt informationssystem, hvor alle algoritmer til at administrere adgangen til det er registreret. Virksomheder, der allerede har implementeret IdM-klasseløsninger, kender sikkert til et sådant spørgeskema, da det er med det, at studiet af systemer begynder.
Nogle af parametrene om systemet og ejere er strømmet ind i spørgeskemaet fra IT-registret (se trin 2, revision), men nye er tilføjet:
- hvordan konti administreres (direkte i databasen eller via programgrænseflader);
- hvordan brugere logger ind på systemet (ved hjælp af en separat konto eller ved hjælp af en AD-konto, LDAP osv.);
- hvilke niveauer af adgang til systemet der bruges (applikationsniveau, systemniveau, brug af netværksfilressourcer af systemet);
- beskrivelse og parametre for de servere, som systemet kører på;
- hvilke kontoadministrationsoperationer der understøttes (blokering, omdøbning osv.);
- hvilke algoritmer eller regler der bruges til at danne systembrugeridentifikationen;
- hvilken egenskab kan bruges til at etablere en forbindelse med en post om en medarbejder i personalesystemet (fuldt navn, personalenummer osv.);
- alle mulige kontoattributter og regler for at udfylde dem;
- hvilke adgangsrettigheder der findes i systemet (roller, grupper, atomrettigheder osv., er der indlejrede eller hierarkiske rettigheder);
- mekanismer til adskillelse af adgangsrettigheder (efter positioner, divisioner, funktionalitet osv.);
- om systemet har regler for adskillelse af rettigheder (SOD - Segregation of Duties), og hvordan de fungerer;
- hvordan fravær, overførsel, afskedigelse, opdatering af medarbejderdata mv behandles i systemet.
Listen kunne fortsætte med detaljerede oplysninger om de forskellige parametre og andre enheder, der er involveret i adgangskontrolprocessen.
Trin 5: Opret en forretningsorienteret autorisationsbeskrivelse
Et andet dokument, som vi får brug for, når vi bygger en rollemodel, er en guide til alle de mulige beføjelser (rettigheder), der kan tildeles brugere i et informationssystem med en detaljeret beskrivelse af den forretningsfunktion, der står bag. Ofte er kræfterne i systemet krypteret med bestemte navne, bestående af bogstaver og tal, og forretningsmedarbejdere kan ikke finde ud af, hvad der ligger bag disse tegn. Så går de til it-servicen, og der ... kan de heller ikke svare på spørgsmålet om for eksempel sjældent brugte rettigheder. Så skal du lave flere test.
Det er godt, hvis der allerede er en forretningsbeskrivelse, eller hvis der er en sammenslutning af disse rettigheder i grupper og roller. For nogle applikationer er den bedste praksis at oprette en sådan vejledning på udviklingsstadiet. Men det sker ikke så tit, så igen går vi til IT-afdelingen for at indsamle information om alle mulige rettigheder og beskrive dem. Vores guide vil i sidste ende indeholde følgende:
- myndighedens navn, herunder den genstand, som adgangsretten gælder for
- den handling, der er tilladt at udføre med objektet (visning, ændring osv., muligheden for begrænsning, for eksempel på et territorialt grundlag eller på en gruppe af klienter);
- autorisationskode (kode og navn på systemfunktionen/anmodningen, der kan udføres ved hjælp af autorisationen);
- beskrivelse af myndigheden (en detaljeret beskrivelse af handlingerne i IS ved anvendelse af myndigheden og deres konsekvenser for processen;
- tilladelsesstatus: "Aktiv" (hvis tilladelsen er tildelt til mindst én bruger) eller "Ikke aktiv" (hvis tilladelsen ikke bruges).
Trin 6 Vi udlæser data om brugere og rettigheder fra systemerne og sammenligner dem med personalekilden
På den sidste fase af forberedelsen skal du uploade data fra informationssystemer om alle brugere og de rettigheder, de har i øjeblikket. To scenarier er mulige her. For det første har sikkerhedsafdelingen direkte adgang til systemet og har midlerne til at downloade de relevante rapporter, hvilket er sjældent, men meget praktisk. For det andet: vi sender en anmodning til IT om at modtage rapporter i det påkrævede format. Praksis viser, at det ikke er muligt at forhandle med IT og få de nødvendige data første gang. Det er nødvendigt at foretage flere tilgange, indtil oplysningerne modtages i den ønskede form og format.
Hvilke data skal uploades:
- Kontonavn
- Navn på den medarbejder, som den er tildelt
- Status (aktiv eller deaktiveret)
- Konto oprettelsesdato
- Sidst brugt dato
- Liste over tilgængelige rettigheder/grupper/roller
Så vi har modtaget aflæsninger fra systemet med alle brugere og med alle de rettigheder, der er givet dem. Og de lægger straks alle blokerede konti til side, da arbejdet med at opbygge en rollemodel kun vil blive udført for aktive brugere.
Så, hvis din virksomhed ikke har automatiserede midler til at lukke adgangen til fyrede medarbejdere (dette er ikke ualmindeligt), eller der er lappeautomatisering, der ikke altid fungerer korrekt, skal du identificere alle de "døde sjæle". Vi taler om konti for allerede afskedigede medarbejdere, hvis rettigheder af en eller anden grund ikke er spærret - de skal spærres. For at gøre dette sammenligner vi de uploadede data med personalekilden. Personaleaflæsning skal også ske på forhånd fra den enhed, der leder personalebasen.
Separat er det nødvendigt at afsætte konti, hvis ejere ikke blev fundet i personalebasen, ikke tildelt nogen - det vil sige ejerløse. Til denne liste har vi brug for datoen for sidste brug: hvis den er ret nylig, skal vi stadig lede efter ejerne. Dette kan omfatte konti fra eksterne entreprenører eller servicekonti, der ikke er tildelt nogen, men som er forbundet med eventuelle processer. For at afklare ejerskabet af kontoen kan du sende breve til alle afdelinger med en anmodning om at svare. Når ejerne er fundet, indtaster vi data om dem i systemet: på denne måde identificeres alle aktive konti, og resten blokeres.
Så snart vores uploads er ryddet for unødvendige poster, og kun aktive konti er tilbage, kan vi begynde at bygge en rollemodel for et specifikt informationssystem. Men jeg vil tale om dette i den næste artikel.
Forfatter: Lyudmila Sevastyanova, Solar inRights Promotion Manager
Kilde: www.habr.com