Implementering af IdM. Forberedelse til implementering hos kunden

I tidligere artikler har vi allerede set på, hvad IdM er, hvordan man forstår, om din organisation har brug for et sådant system, hvilke problemer det løser, og hvordan man retfærdiggør implementeringsbudgettet over for ledelsen. I dag vil vi tale om de vigtige stadier, som organisationen selv skal igennem for at opnå det rette modenhedsniveau før implementering af et IdM-system. IdM er jo designet til at automatisere processer, men det er umuligt at automatisere kaos.

Indtil en virksomhed vokser til størrelsen af ​​en stor virksomhed og har akkumuleret en masse forskellige forretningssystemer, tænker den normalt ikke på adgangskontrol. Derfor er processerne med at opnå rettigheder og kontrolbeføjelser i den ikke strukturerede og vanskelige at analysere. Medarbejdere udfylder ansøgninger om adgang, som de ønsker, godkendelsesprocessen er heller ikke formaliseret, og nogle gange eksisterer den simpelthen ikke. Det er umuligt hurtigt at finde ud af, hvilken adgang en medarbejder har, hvem der har godkendt den og på hvilket grundlag.

I betragtning af, at processen med automatisering af adgang påvirker to hovedaspekter - personaledata og data fra informationssystemer, som integrationen skal udføres med, vil vi overveje de nødvendige skridt for at sikre, at implementeringen af ​​IdM går glat og ikke forårsager afvisning:

1. Analyse af personaleprocesser og optimering af medarbejderdatabaseunderstøttelse i personalesystemer.
2. Analyse af bruger- og rettighedsdata, samt opdatering af adgangskontrolmetoder i målsystemer, der planlægges tilsluttet IdM.
3. Organisatoriske aktiviteter og personaleinvolvering i processen med at forberede implementering af IdM.

Personaledata

Der kan være én kilde til personaledata i en organisation, eller der kan være flere. For eksempel kan en organisation have et ret bredt filialnet, og hver filial kan bruge sin egen personalebase.

Først og fremmest er det nødvendigt at forstå, hvilke grundlæggende data om medarbejdere der er gemt i personaleregistreringssystemet, hvilke hændelser der registreres og evaluere deres fuldstændighed og struktur.

Det sker ofte, at ikke alle personalehændelser noteres i personalekilden (og endnu oftere noteres de i utide og ikke helt korrekt). Her er nogle typiske eksempler:

• Blade, deres kategorier og termer (regelmæssige eller langsigtede) registreres ikke;
• Deltidsbeskæftigelse registreres ikke: for eksempel, mens en medarbejder er på langtidsorlov for at passe et barn, kan en medarbejder samtidig arbejde deltid;
• den faktiske status for kandidaten eller medarbejderen er allerede ændret (modtagelse/overførsel/afskedigelse), og ordren om denne begivenhed udstedes med en forsinkelse;
• en medarbejder overflyttes til en ny ordinær stilling ved afskedigelse, mens personalesystemet ikke registrerer oplysninger om, at der er tale om en teknisk afskedigelse.

Det er også værd at være særlig opmærksom på at vurdere kvaliteten af ​​data, da eventuelle fejl og unøjagtigheder opnået fra en betroet kilde, som er HR-systemer, kan være dyrt i fremtiden og give mange problemer ved implementering af IdM. Fx indtaster HR-medarbejdere ofte medarbejderstillinger i personalesystemet i forskellige formater: store og små bogstaver, forkortelser, forskellige antal mellemrum og lignende. Som et resultat kan den samme position registreres i personalesystemet i følgende variationer:

• Seniorchef
• øverste leder
• øverste leder
• Kunst. Manager…

Ofte er du nødt til at forholde dig til forskelle i stavningen af ​​dit navn:

• Shmeleva Natalya Gennadievna,
• Shmeleva Natalia Gennadievna...

For yderligere automatisering er et sådant virvar uacceptabelt, især hvis disse attributter er et nøgletegn på identifikation, det vil sige, at data om medarbejderen og hans beføjelser i systemerne sammenlignes med det fulde navn.

Derudover bør vi ikke glemme den mulige tilstedeværelse af navne- og fulde navnebrødre i virksomheden. Hvis en organisation har tusind ansatte, kan der være få sådanne matches, men hvis der er 50 tusinde, så kan dette blive en kritisk hindring for den korrekte drift af IdM-systemet.

Sammenfattende alt ovenstående konkluderer vi: formatet for indtastning af data i organisationens personaledatabase skal standardiseres. Parametrene for indtastning af navne, stillinger og afdelinger skal være klart definerede. Den bedste mulighed er, når en HR-medarbejder ikke indtaster data manuelt, men vælger dem fra en på forhånd oprettet mappe over strukturen af ​​afdelinger og stillinger ved hjælp af "vælg"-funktionen, der er tilgængelig i personaledatabasen.

For at undgå yderligere fejl i synkroniseringen og ikke manuelt at skulle korrigere uoverensstemmelser i rapporter, den mest foretrukne måde at identificere medarbejdere på er at indtaste et ID for hver medarbejder i organisationen. En sådan identifikator vil blive tildelt hver ny medarbejder og vil optræde både i personalesystemet og i organisationens informationssystemer som en obligatorisk kontoattribut. Det er lige meget om det består af tal eller bogstaver, det vigtigste er, at det er unikt for hver enkelt medarbejder (mange bruger f.eks. medarbejderens personalenummer). I fremtiden vil indførelsen af ​​denne attribut i høj grad lette sammenkædningen af ​​medarbejderdata i personalekilden med hans konti og myndigheder i informationssystemer.

Så alle trin og mekanismer i personaleregistreringer skal analyseres og bringes i orden. Det er meget muligt, at nogle processer skal ændres eller modificeres. Dette er kedeligt og omhyggeligt arbejde, men det er nødvendigt, ellers vil manglen på klare og strukturerede data om personalehændelser føre til fejl i deres automatiske behandling. I værste fald vil ustrukturerede processer overhovedet være umulige at automatisere.

Målsystemer

På næste trin skal vi finde ud af, hvor mange informationssystemer vi ønsker at integrere i IdM-strukturen, hvilke data om brugere og deres rettigheder, der er gemt i disse systemer, og hvordan de skal administreres.

I mange organisationer er der en opfattelse af, at vi vil installere IdM, konfigurere forbindelser til målsystemerne, og med en bølge af en tryllestav vil alt fungere uden yderligere indsats fra vores side. Det sker desværre ikke. I virksomheder udvikler informationssystemlandskabet sig og stiger gradvist. Hvert system kan have en forskellig tilgang til at give adgangsrettigheder, det vil sige, at forskellige adgangskontrolgrænseflader kan konfigureres. Et eller andet sted foregår kontrol gennem en API (applikationsprogrammeringsgrænseflade), et eller andet sted gennem en database ved hjælp af lagrede procedurer, et eller andet sted er der muligvis ingen interaktionsgrænseflader overhovedet. Du bør være forberedt på, at du bliver nødt til at genoverveje mange eksisterende processer til styring af konti og rettigheder i organisationens systemer: ændre dataformatet, forbedre interaktionsgrænseflader på forhånd og allokere ressourcer til dette arbejde.

Rollemodel

Du vil sandsynligvis støde på begrebet rollemodel i forbindelse med valget af IdM-løsningsudbyder, da dette er et af nøglebegreberne inden for adgangsretsstyring. I denne model gives adgang til data gennem en rolle. En rolle er et sæt af adgange, der er minimalt nødvendige for, at en medarbejder i en bestemt stilling kan udføre deres funktionelle ansvar.

Rollebaseret adgangskontrol har en række ubestridelige fordele:

• det er enkelt og effektivt at tildele de samme rettigheder til et stort antal ansatte;
• øjeblikkelig ændring af adgangen for medarbejdere med samme sæt rettigheder;
• eliminering af redundans af rettigheder og afgrænsning af inkompatible beføjelser for brugere.

Rollematricen bygges først separat i hvert af organisationens systemer og skaleres derefter til hele it-landskabet, hvor globale forretningsroller dannes ud fra hvert systems roller. For eksempel vil forretningsrollen "Revisor" omfatte flere separate roller for hvert af de informationssystemer, der bruges i virksomhedens regnskabsafdeling.

For nylig er det blevet betragtet som "best practice" at skabe en rollemodel selv på stadiet med udvikling af applikationer, databaser og operativsystemer. Samtidig er der ofte situationer, hvor roller ikke er konfigureret i systemet, eller de simpelthen ikke eksisterer. I dette tilfælde skal administratoren af ​​dette system indtaste kontooplysninger i flere forskellige filer, biblioteker og mapper, der giver de nødvendige tilladelser. Brugen af ​​foruddefinerede roller giver dig mulighed for at give privilegier til at udføre en lang række operationer i et system med komplekse sammensatte data.

Roller i et informationssystem er som udgangspunkt fordelt på stillinger og afdelinger efter bemandingsstrukturen, men kan også oprettes til bestemte forretningsprocesser. For eksempel, i en finansiel organisation, indtager flere medarbejdere i afregningsafdelingen den samme stilling - operatør. Men inden for afdelingen er der også en fordeling i separate processer, efter forskellige typer operationer (eksterne eller interne, i forskellige valutaer, med forskellige segmenter af organisationen). For at give hvert af forretningsområderne i én afdeling adgang til informationssystemet i overensstemmelse med de nødvendige detaljer, er det nødvendigt at inkludere rettigheder i individuelle funktionelle roller. Dette vil gøre det muligt at give et tilstrækkeligt minimum af beføjelser, som ikke omfatter overflødige rettigheder, for hvert af aktivitetsområderne.

For store systemer med hundredvis af roller, tusindvis af brugere og millioner af tilladelser er det desuden god praksis at bruge et hierarki af roller og privilegiearv. For eksempel vil den overordnede rolle Administrator arve rettighederne for de underordnede roller: Bruger og Læser, da administratoren kan gøre alt, hvad brugeren og læseren kan gøre, plus vil have yderligere administrative rettigheder. Ved at bruge hierarki er det ikke nødvendigt at genspecificere de samme rettigheder i flere roller i det samme modul eller system.

På det første trin kan du oprette roller i de systemer, hvor det mulige antal kombinationer af rettigheder ikke er særlig stort, og som følge heraf er det nemt at administrere et lille antal roller. Det kan være typiske rettigheder, som alle medarbejdere i virksomheden kræver til offentligt tilgængelige systemer som Active Directory (AD), mailsystemer, Service Manager og lignende. Derefter kan de oprettede rollematricer for informationssystemer inkluderes i den generelle rollemodel, og kombinere dem i forretningsroller.

Ved at bruge denne tilgang vil det i fremtiden, når man implementerer et IdM-system, være let at automatisere hele processen med at tildele adgangsrettigheder baseret på de oprettede førstetrinsroller.

NB Du bør ikke forsøge umiddelbart at inkludere så mange systemer som muligt i integrationen. Det er bedre at forbinde systemer med en mere kompleks arkitektur og adgangsrettighedsstyringsstruktur til IdM i en semi-automatisk tilstand i første fase. Det vil sige, implementer, baseret på personalehændelser, kun den automatiske generering af en adgangsanmodning, som vil blive sendt til administratoren til udførelse, og han vil konfigurere rettighederne manuelt.

Efter at have gennemført den første fase, kan du udvide systemets funktionalitet til nye udvidede forretningsprocesser, implementere fuld automatisering og skalering med tilslutning af yderligere informationssystemer.

Med andre ord, for at forberede implementeringen af ​​IdM er det nødvendigt at vurdere informationssystemernes parathed til den nye proces og på forhånd at færdiggøre de eksterne interaktionsgrænseflader til styring af brugerkonti og brugerrettigheder, hvis sådanne grænseflader ikke er tilgængelig i systemet. Spørgsmålet om trin-for-trin oprettelse af roller i informationssystemer til omfattende adgangskontrol bør også undersøges.

Organisatoriske begivenheder

Undgå heller ikke organisatoriske problemer. I nogle tilfælde kan de spille en afgørende rolle, fordi resultatet af hele projektet ofte afhænger af et effektivt samspil mellem afdelingerne. For at gøre dette råder vi normalt til at oprette et team af procesdeltagere i organisationen, som vil omfatte alle de involverede afdelinger. Da dette er en ekstra byrde for folk, så prøv på forhånd at forklare alle deltagere i den fremtidige proces deres rolle og betydning i interaktionsstrukturen. Hvis du "sælger" ideen om IdM til dine kolleger på dette tidspunkt, kan du undgå mange vanskeligheder i fremtiden.

Ofte er informationssikkerheden eller it-afdelingerne "ejere" af IdM-implementeringsprojektet i en virksomhed, og der tages ikke hensyn til forretningsafdelingernes holdninger. Det er en stor fejl, for det er kun de, der ved, hvordan og i hvilke forretningsprocesser hver ressource bruges, hvem der skal have adgang til den, og hvem der ikke skal. Derfor er det i forberedelsesfasen vigtigt at markere, at det er virksomhedsejeren, der er ansvarlig for den funktionelle model, ud fra hvilke sæt af brugerrettigheder (roller) i informationssystemet udvikles, samt for at sikre, at disse roller holdes ajour. En rollemodel er ikke en statisk matrix, der bygges én gang, og man kan falde til ro på den. Der er tale om en "levende organisme", som hele tiden skal ændres, opdateres og udvikles efter ændringer i organisationens struktur og medarbejdernes funktionalitet. Ellers vil der enten opstå problemer i forbindelse med forsinkelser i at give adgang, eller der vil opstå informationssikkerhedsrisici forbundet med for store adgangsrettigheder, hvilket er endnu værre.

"Syv barnepige har som bekendt et barn uden øje", så virksomheden skal udvikle en metodik, der beskriver rollemodellens arkitektur, samspillet og ansvaret hos specifikke deltagere i processen for at holde den opdateret. Hvis en virksomhed har mange forretningsområder og dermed mange divisioner og afdelinger, så er det for hvert område (f.eks. udlån, operationelt arbejde, fjerntjenester, compliance og andre) som en del af den rollebaserede adgangsstyringsproces. er nødvendigt at udpege separate kuratorer. Gennem dem vil det være muligt hurtigt at modtage information om ændringer i afdelingens struktur og de nødvendige adgangsrettigheder for hver rolle.

Det er bydende nødvendigt at få støtte fra organisationens ledelse til at løse konfliktsituationer mellem afdelinger, der deltager i processen. Og konflikter, når man introducerer enhver ny proces, er uundgåelige, tro vores erfaring. Derfor har vi brug for en voldgiftsmand, der løser mulige interessekonflikter, for ikke at spilde tid på grund af andres misforståelser og sabotage.

NB Et godt sted at begynde at øge bevidstheden er at uddanne dit personale. En detaljeret undersøgelse af funktionen af ​​den fremtidige proces og hver enkelt deltagers rolle i den vil minimere vanskelighederne ved overgangen til en ny løsning.

Tjekliste

For at opsummere opsummerer vi de vigtigste trin, som en organisation, der planlægger at implementere IdM, bør tage:

• bringe orden i personaledata;
• indtast en unik identifikationsparameter for hver medarbejder;
• vurdere informationssystemers beredskab til implementering af IdM;
• udvikle grænseflader til interaktion med informationssystemer til adgangskontrol, hvis de mangler, og allokere ressourcer til dette arbejde;
• udvikle og opbygge en rollemodel;
• opbygge en rollemodelstyringsproces og inkludere kuratorer fra hvert forretningsområde i den;
• vælge flere systemer til indledende forbindelse til IdM;
• skabe et effektivt projektteam;
• få støtte fra virksomhedens ledelse;
• uddanne personale.

Forberedelsesprocessen kan være svær, så involver om muligt konsulenter.

Implementering af en IdM-løsning er et vanskeligt og ansvarligt skridt, og for dens succesfulde implementering er både indsatsen fra hver enkelt part individuelt – medarbejdere i forretningsafdelinger, IT- og informationssikkerhedstjenester og samspillet mellem hele teamet som helhed vigtig. Men indsatsen er det værd: Efter implementering af IdM i en virksomhed falder antallet af hændelser relateret til overdrevne beføjelser og uautoriserede rettigheder i informationssystemer; medarbejdernes nedetid på grund af manglende/lang ventetid på nødvendige rettigheder forsvinder; På grund af automatisering reduceres lønomkostningerne, og arbejdsproduktiviteten for it- og informationssikkerhedstjenester øges.

Kilde: www.habr.com