I tidligere artikler har vi allerede sett på hva IdM er, hvordan du forstår om din organisasjon trenger et slikt system, hvilke problemer det løser, og hvordan du kan rettferdiggjøre implementeringsbudsjettet overfor ledelsen. I dag skal vi snakke om de viktige stadiene som organisasjonen selv må gjennom for å oppnå riktig modenhet før implementering av et IdM-system. Tross alt er IdM designet for å automatisere prosesser, men det er umulig å automatisere kaos.
Inntil et selskap vokser til størrelsen på en stor bedrift og har akkumulert mange forskjellige forretningssystemer, tenker det vanligvis ikke på tilgangskontroll. Derfor er prosessene for å oppnå rettigheter og kontrollmakter i den ikke strukturert og vanskelig å analysere. Ansatte fyller ut søknader om tilgang slik de ønsker, godkjenningsprosessen er heller ikke formalisert, og noen ganger eksisterer den rett og slett ikke. Det er umulig å raskt finne ut hvilken tilgang en ansatt har, hvem som har godkjent den og på hvilket grunnlag.
Tatt i betraktning at prosessen med å automatisere tilgang påvirker to hovedaspekter – personelldata og data fra informasjonssystemer som integrasjon skal utføres med, vil vi vurdere trinnene som er nødvendige for å sikre at implementeringen av IdM går problemfritt og ikke forårsaker avvisning:
- Analyse av personalprosesser og optimalisering av medarbeiderdatabasestøtte i personalsystemer.
- Analyse av bruker- og rettighetsdata, samt oppdatering av tilgangskontrollmetoder i målsystemer som planlegges koblet til IdM.
- Organisatoriske aktiviteter og personell involvering i prosessen med å forberede implementering av IdM.
Personaldata
Det kan være én kilde til personelldata i en organisasjon, eller det kan være flere. For eksempel kan en organisasjon ha et ganske bredt filialnettverk, og hver filial kan bruke sin egen personalbase.
Først av alt er det nødvendig å forstå hvilke grunnleggende data om ansatte som er lagret i personaljournalsystemet, hvilke hendelser som registreres, og vurdere deres fullstendighet og struktur.
Det hender ofte at ikke alle personalhendelser blir notert i personalkilden (og enda oftere noteres de i utide og ikke helt korrekt). Her er noen typiske eksempler:
- Blader, deres kategorier og vilkår (vanlige eller langsiktige) er ikke registrert;
- Deltidsarbeid registreres ikke: for eksempel, mens han er på langtidspermisjon for å ta seg av et barn, kan en ansatt samtidig jobbe deltid;
- den faktiske statusen til kandidaten eller ansatt er allerede endret (mottak/overføring/avskjed), og ordren om denne hendelsen utstedes med en forsinkelse;
- en arbeidstaker overføres til ny ordinær stilling ved oppsigelse, mens personalsystemet ikke registrerer opplysninger om at dette er en teknisk oppsigelse.
Det er også verdt å være spesielt oppmerksom på å vurdere kvaliteten på data, siden eventuelle feil og unøyaktigheter hentet fra en pålitelig kilde, som er HR-systemer, kan være kostbare i fremtiden og forårsake mange problemer ved implementering av IdM. For eksempel legger HR-ansatte ofte inn ansattes stillinger i personalsystemet i ulike formater: store og små bokstaver, forkortelser, ulike antall mellomrom og lignende. Som et resultat kan den samme stillingen registreres i personellsystemet i følgende variasjoner:
- Seniorsjef
- øverste leder
- øverste leder
- Kunst. sjef…
Ofte må du forholde deg til forskjeller i stavemåten til navnet ditt:
- Shmeleva Natalya Gennadievna,
- Shmeleva Natalia Gennadievna...
For ytterligere automatisering er et slikt virvar uakseptabelt, spesielt hvis disse attributtene er et nøkkeltegn på identifikasjon, det vil si at data om den ansatte og hans krefter i systemene sammenlignes nøyaktig med fullt navn.
I tillegg bør vi ikke glemme den mulige tilstedeværelsen av navnebror og fulle navnebror i selskapet. Hvis en organisasjon har tusen ansatte kan det være få slike treff, men er det 50 tusen, så kan dette bli et kritisk hinder for riktig drift av IdM-systemet.
Ved å oppsummere alt ovenfor, konkluderer vi: formatet for å legge inn data i organisasjonens personaldatabase må standardiseres. Parametrene for å legge inn navn, stillinger og avdelinger må være klart definert. Det beste alternativet er når en HR-ansatt ikke legger inn data manuelt, men velger dem fra en forhåndsopprettet katalog over strukturen til avdelinger og stillinger ved å bruke "velg"-funksjonen som er tilgjengelig i personaldatabasen.
For å unngå ytterligere feil i synkroniseringen og ikke må manuelt korrigere avvik i rapporter, den mest foretrukne måten å identifisere ansatte på er å angi en ID for hver ansatt i organisasjonen. En slik identifikator vil bli tildelt hver nyansatt og vil vises både i personalsystemet og i organisasjonens informasjonssystemer som et obligatorisk kontoattributt. Det spiller ingen rolle om det består av tall eller bokstaver, det viktigste er at det er unikt for hver ansatt (for eksempel bruker mange ansattes personnummer). I fremtiden vil innføringen av dette attributtet i stor grad lette koblingen av ansattes data i personalkilden med hans kontoer og myndigheter i informasjonssystemer.
Så alle trinnene og mekanismene til personaljournaler må analyseres og settes i orden. Det er godt mulig at noen prosesser må endres eller modifiseres. Dette er kjedelig og møysommelig arbeid, men det er nødvendig, ellers vil mangelen på klare og strukturerte data om personalhendelser føre til feil i deres automatiske behandling. I verste fall vil ustrukturerte prosesser være umulige å automatisere i det hele tatt.
Målsystemer
På neste trinn må vi finne ut hvor mange informasjonssystemer vi ønsker å integrere i IdM-strukturen, hvilke data om brukere og deres rettigheter som er lagret i disse systemene, og hvordan de skal administreres.
I mange organisasjoner er det en oppfatning at vi vil installere IdM, konfigurere koblinger til målsystemene, og med en bølge av en tryllestav vil alt fungere, uten ekstra innsats fra vår side. Det skjer dessverre ikke. I bedrifter er informasjonssystemlandskapet i utvikling og øker gradvis. Hvert system kan ha en annen tilnærming til å gi tilgangsrettigheter, det vil si at forskjellige tilgangskontrollgrensesnitt kan konfigureres. Et sted skjer kontroll gjennom et API (applikasjonsprogrammeringsgrensesnitt), et sted gjennom en database som bruker lagrede prosedyrer, et sted kan det ikke være noen interaksjonsgrensesnitt i det hele tatt. Du bør være forberedt på at du må revurdere mange eksisterende prosesser for å administrere kontoer og rettigheter i organisasjonens systemer: endre dataformat, forbedre interaksjonsgrensesnitt på forhånd og allokere ressurser til dette arbeidet.
Forbilde
Du vil sannsynligvis komme over konseptet med en rollemodell ved valg av IdM-løsningsleverandør, siden dette er et av nøkkelbegrepene innen tilgangsrettighetsadministrasjon. I denne modellen gis tilgang til data gjennom en rolle. En rolle er et sett med tilganger som er minimalt nødvendige for at en ansatt i en bestemt posisjon skal utføre sitt funksjonelle ansvar.
Rollebasert tilgangskontroll har en rekke ubestridelige fordeler:
- det er enkelt og effektivt å tildele de samme rettighetene til et stort antall ansatte;
- raskt endre tilgangen til ansatte med samme sett med rettigheter;
- eliminere redundans av rettigheter og avgrense inkompatible krefter for brukere.
Rollematrisen bygges først separat i hvert av organisasjonens systemer, og skaleres deretter til hele IT-landskapet, der globale forretningsroller dannes fra rollene til hvert system. For eksempel vil Forretningsrollen «Regnskapsfører» inkludere flere separate roller for hvert av informasjonssystemene som brukes i regnskapsavdelingen til bedriften.
Nylig har det blitt ansett som "beste praksis" å skape en rollemodell selv på stadiet med utvikling av applikasjoner, databaser og operativsystemer. Samtidig er det ofte situasjoner der roller ikke er konfigurert i systemet eller de rett og slett ikke eksisterer. I dette tilfellet må administratoren av dette systemet legge inn kontoinformasjon i flere forskjellige filer, biblioteker og kataloger som gir de nødvendige tillatelsene. Bruken av forhåndsdefinerte roller lar deg gi privilegier til å utføre en hel rekke operasjoner i et system med komplekse sammensatte data.
Roller i et informasjonssystem er som regel fordelt på stillinger og avdelinger i henhold til bemanningsstrukturen, men kan også opprettes for enkelte forretningsprosesser. For eksempel, i en finansiell organisasjon, har flere ansatte i oppgjørsavdelingen samme stilling - operatør. Men innenfor avdelingen er det også en fordeling i separate prosesser, i henhold til ulike typer operasjoner (ekstern eller intern, i ulike valutaer, med ulike segmenter av organisasjonen). For å gi hvert av forretningsområdene til én avdeling tilgang til informasjonssystemet i henhold til de nødvendige spesifikasjonene, er det nødvendig å inkludere rettigheter i individuelle funksjonelle roller. Dette vil gjøre det mulig å gi et minimum tilstrekkelig sett med fullmakter, som ikke inkluderer overflødige rettigheter, for hvert av aktivitetsområdene.
I tillegg, for store systemer med hundrevis av roller, tusenvis av brukere og millioner av tillatelser, er det god praksis å bruke et hierarki av roller og rettighetsarv. For eksempel vil den overordnede rollen Administrator arve privilegiene til de underordnede rollene: Bruker og Leser, siden Administratoren kan gjøre alt som brukeren og Leseren kan gjøre, pluss vil ha ytterligere administrative rettigheter. Ved å bruke hierarki er det ikke nødvendig å spesifisere de samme rettighetene på nytt i flere roller i samme modul eller system.
På det første trinnet kan du opprette roller i de systemene der det mulige antallet kombinasjoner av rettigheter ikke er veldig stort, og som et resultat er det enkelt å administrere et lite antall roller. Dette kan være typiske rettigheter som kreves av alle ansatte i selskapet til offentlig tilgjengelige systemer som Active Directory (AD), postsystemer, Service Manager og lignende. Deretter kan de opprettede rollematrisene for informasjonssystemer inkluderes i den generelle rollemodellen, og kombinere dem til forretningsroller.
Ved å bruke denne tilnærmingen, i fremtiden, når du implementerer et IdM-system, vil det være enkelt å automatisere hele prosessen med å gi tilgangsrettigheter basert på de opprettede første trinnsrollene.
NB Du bør ikke prøve å inkludere så mange systemer som mulig umiddelbart i integrasjonen. Det er bedre å koble systemer med en mer kompleks arkitektur og administrasjonsstruktur for tilgangsrettigheter til IdM i en halvautomatisk modus i det første trinnet. Det vil si, implementer, basert på personalhendelser, kun den automatiske genereringen av en tilgangsforespørsel, som vil bli sendt til administratoren for utførelse, og han vil konfigurere rettighetene manuelt.
Etter å ha fullført den første fasen, kan du utvide funksjonaliteten til systemet til nye utvidede forretningsprosesser, implementere full automatisering og skalering med tilkobling av tilleggsinformasjonssystemer.
Med andre ord, for å forberede implementeringen av IdM, er det nødvendig å vurdere beredskapen til informasjonssystemene for den nye prosessen og å ferdigstille på forhånd de eksterne interaksjonsgrensesnittene for administrasjon av brukerkontoer og brukerrettigheter, dersom slike grensesnitt ikke er det. tilgjengelig i systemet. Spørsmålet om trinnvis opprettelse av roller i informasjonssystemer for omfattende tilgangskontroll bør også utforskes.
Organisasjonsarrangementer
Ikke diskonter organisatoriske problemer heller. I noen tilfeller kan de spille en avgjørende rolle, fordi utfallet av hele prosjektet ofte er avhengig av effektivt samspill mellom avdelingene. For å gjøre dette anbefaler vi vanligvis å opprette et team av prosessdeltakere i organisasjonen, som vil inkludere alle involverte avdelinger. Siden dette er en ekstra belastning for folk, prøv å forklare på forhånd for alle deltakere i den fremtidige prosessen deres rolle og betydning i samhandlingsstrukturen. Hvis du "selger" ideen om IdM til kollegene dine på dette stadiet, kan du unngå mange vanskeligheter i fremtiden.
Ofte er informasjonssikkerhets- eller IT-avdelingene "eiere" av IdM-implementeringsprosjektet i et selskap, og meninger fra forretningsavdelinger blir ikke tatt i betraktning. Dette er en stor feil, fordi bare de vet hvordan og i hvilke forretningsprosesser hver ressurs brukes, hvem som skal få tilgang til den og hvem som ikke skal. Derfor er det på forberedelsesstadiet viktig å indikere at det er bedriftseieren som er ansvarlig for funksjonsmodellen på grunnlag av hvilke sett med brukerrettigheter (roller) i informasjonssystemet som utvikles, samt for å sikre at disse rollene holdes oppdatert. Et forbilde er ikke en statisk matrise som bygges en gang og du kan roe deg ned på den. Dette er en «levende organisme» som hele tiden må endres, oppdateres og utvikles, etter endringer i strukturen i organisasjonen og funksjonaliteten til ansatte. Ellers vil det enten oppstå problemer knyttet til forsinkelser i å gi tilgang, eller informasjonssikkerhetsrisiko knyttet til overdreven tilgangsrettigheter, noe som er enda verre.
Som du vet, «sju barnepiker har et barn uten øye», så selskapet må utvikle en metodikk som beskriver rollemodellens arkitektur, samspillet og ansvaret til spesifikke deltakere i prosessen for å holde den oppdatert. Hvis et selskap har mange forretningsområder og følgelig mange divisjoner og avdelinger, vil det for hvert område (for eksempel utlån, driftsarbeid, eksterne tjenester, compliance og andre) som en del av den rollebaserte tilgangsadministrasjonsprosessen. er nødvendig å utnevne separate kuratorer. Gjennom dem vil det være mulig å raskt få informasjon om endringer i avdelingens struktur og tilgangsrettigheter som kreves for hver rolle.
Det er viktig å få støtte fra organisasjonens ledelse for å løse konfliktsituasjoner mellom avdelinger som deltar i prosessen. Og konflikter når man introduserer en ny prosess er uunngåelige, tror vår erfaring. Derfor trenger vi en voldgiftsdommer som vil løse mulige interessekonflikter, for ikke å kaste bort tid på grunn av andres misforståelser og sabotasje.
NB Et godt sted å begynne for å øke bevisstheten er å lære opp personalet ditt. En detaljert studie av funksjonen til den fremtidige prosessen og rollen til hver deltaker i den vil minimere vanskelighetene med å gå over til en ny løsning.
Sjekkliste
For å oppsummere, oppsummerer vi hovedtrinnene som en organisasjon som planlegger å implementere IdM bør ta:
- bringe orden på personelldata;
- angi en unik identifikasjonsparameter for hver ansatt;
- vurdere beredskapen til informasjonssystemer for implementering av IdM;
- utvikle grensesnitt for samhandling med informasjonssystemer for adgangskontroll, dersom de mangler, og tildele ressurser til dette arbeidet;
- utvikle og bygge en rollemodell;
- bygge en rollemodellstyringsprosess og inkludere kuratorer fra hvert forretningsområde i den;
- velg flere systemer for første tilkobling til IdM;
- skape et effektivt prosjektteam;
- få støtte fra bedriftsledelsen;
- trene ansatte.
Forberedelsesprosessen kan være vanskelig, så involver konsulenter om mulig.
Implementering av en IdM-løsning er et vanskelig og ansvarlig skritt, og for vellykket implementering er både innsatsen til hver enkelt part individuelt – ansatte i forretningsavdelinger, IT- og informasjonssikkerhetstjenester, og samhandlingen mellom hele teamet som helhet viktig. Men innsatsen er verdt det: etter implementering av IdM i et selskap, reduseres antallet hendelser knyttet til overdreven fullmakter og uautoriserte rettigheter i informasjonssystemer; ansattes nedetid på grunn av manglende/lang ventetid på nødvendige rettigheter forsvinner; På grunn av automatisering reduseres arbeidskostnadene og arbeidsproduktiviteten til IT- og informasjonssikkerhetstjenester økes.
Kilde: www.habr.com