Juho Erkkilä

Pääsynhallintamenetelmät ja niidentehostaminenIT-ulkoistuspalveluntarjoajannäkökulmasta

Sähkötekniikan korkeakoulu

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi

diplomi-insinöörin tutkintoa varten Espoossa 23.5.2012.

Työn valvoja:

Dos. Kalevi Kilkki

Työn ohjaaja:

DI Arsi Heinonen

A? Aalto-yliopistoSähkötekniikankorkeakoulu

aalto-yliopisto

sähkötekniikan korkeakoulu

diplomityön

tiivistelmä

Tekijä: Juho Erkkilä

Työn nimi: Pääsynhallintamenetelmät ja niiden tehostaminenIT-ulkoistuspalveluntarjoajan näkökulmasta

Päivämäärä: 23.5.2012 Kieli: Suomi Sivumäärä:10+69

Tietoliikenne- ja tietoverkkotekniikan laitos

Professuuri: Tietoverkkotalous Koodi: ETA3003

Valvoja: Dos. Kalevi Kilkki

Ohjaaja: DI Arsi Heinonen

Diplomityössä esitellään pääsynhallinta osana IT palvelutoimintaa, tutustutaanerilaisiin pääsynhallintamenetelmiin, ja pohditaan miten pääsynhallintaa voitai-siin tehostaa IT ulkoistuspalveluntarjoajan näkökulmasta. Pääsynhallintamene-telmät luottavat olemassa oleviin tietoturvan- ja identiteetinhallintamenetelmiinpyrkien toteuttamaan sovittua tietoturvapolitiikkaa.

Työssä esitellään tapaustutkimuksena miten pääsynhallinta on määritelty pal-veluna IT-ulkoistuspalveluita tarjoavassa yrityksessä ja millaisin menetelminpääsynhallintaa yrityksessä toteutetaan. Tapaustutkimuksen tulokset osoittavat,että pääsynhallinta on puutteellisesti toteutettu, johtuen osittain siitä, etteipääsynhallintaa ole määritelty yrityksessä palvelutoiminnoksi.

Pääsynhallinnan parantamiselle yrityksessä esitellään toteuttamisehdotus, jonkatarkoituksena on tarjota kattava kokonaiskuva siitä, miten pääsynhallinta voi-taisiin IT-ulkoistuspalveluita tarjoavassa yrityksessä toteuttaa. Pääsynhallintakuvattiin yhdeksi palvelutoiminnoksi siten, että se osaltaan lisäisi yrityksentietoturvaa ja tehostaisi käyttöoikeuspyyntöjen hallintaa ja toteutusta.

Arvioinnin perusteella toteutusehdotus on yritykselle suositeltava toteuttaa. Setarjoaa tehokkaaman tavan hallinnoida ja toteuttaa käyttöoikeuspyyntöjä ja lisääosaltaan yrityksen tietoturvaa. RBAC perustainen pääsynhallinta myös mahdollis-taa toimintatavan linjaamisen yleisten alan parhaiden käytäntöjen ja standardienkanssa.

Avainsanat: Pääsynhallinta, pääsyn kontrollointi, käyttöoikeuksien hallinta,identiteetinhallinta, IAM, DAC, MAC, RBAC, tietoturvapolitiikka,reference monitor

aalto university

school of electrical engineering

abstract of the

master's thesis

Author: Juho Erkkilä

Title: Access management methods and enhancement of the methods in ITOutsoursing Service Provider organization

Date: 23.5.2012 Language: Finnish Number of pages:10+69

Department of Communications and Networking

Professorship: Communications Ecosystem Code: ETA3003

Supervisor: Docent Kalevi Kilkki

Instructor: M.Sc. (Tech.) Arsi Heinonen

This master's thesis introduces access management as a part of IT serviceactivities, discusses how di�erent access management methods are used in ITOutsoursing Service Provider organization, and how those could be enhanced.Access management methods relies on information security management andidentity management, which provide essential policies and methods required forperforming access management.

A case study was performed to IT Outsoursing Service Provider organization tostudy how the access management is de�ned as a service and with what kindof methods and tools access management is carried out within the organization.Gathered results from the case study reveal that current way of performing accessmanagement within the organization is de�cient partly because it has not beenrecoqnized as a service activity.

To enhance the access management within the organization, an implementationproposal was constructed. Proposal provides a comprehensive overview howaccess management could be de�ned and implemented within the organization.Access management was de�ned as a service in a way that it would increaseorganizations information security and improve the management and realizationof the access requests.

Based on the evaluation, the implementation proposal is recommended for theorganization. It increases the e�ciency of the management and realization of theaccess request as well as organization overal information security. By introducingRBAC based access management, proposal enables access management activitiesto be in line with industry's best practices and standards.

Keywords: Access Management, Access Control, User rights management, Iden-tity Management, IAM, DAC, MAC, RBAC, Information SecurityPolicy, Reference Monitor

iv

Esipuhe

Haluan kiittää Dosentti Kalevi Kilkkiä kärsivällisyydestä työn edistymisessä ja kan-nustavasta asenteesta työtä kohtaan. Ohjaaja Arsi Heinosta haluan kiittää laaja-alaisesta asiantuntemuksesta ja näkemyksen antamisesta työhön sekä hyvästä oh-jauksesta. Kiitos Atos IT Solutions and Services Oy:lle mahdollisuudesta tehdädiplomityö yritykselle. Henkilöt, joiden kanssa olen saanut yrityksessä työskennelläovat mitä parhaimpia työkavereita ja olen saanut heiltä paljon apua ja tukea niindiplomityön suorittamisessa kuin muissa työtehtävissä. Kiitos teille.

Erityismaininta Niina Järviselle tukemisesta, oikolukemisesta, jaksamisesta jakannustamisesta työn etenemisen aikana. Kiitos!

Otaniemi, 23.05.2012

Juho Erkkilä

v

Sisältö

Tiivistelmä ii

Tiivistelmä (englanniksi) iii

Esipuhe iv

Sisällysluettelo v

Lyhenteet ja termit vii

1 Johdanto 11.1 Tausta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Tutkimusongelma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Arviointikriteeri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Diplomityön rakenne . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Palvelunhallinta IT palveluorganisaatiossa 52.1 Serti�oinnin tarpeellisuus . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Tietoturva 93.1 Tietoturvan hallinta . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Tehtävien eriyttäminen (SoD) . . . . . . . . . . . . . . . . . . 113.1.2 Pienimmän oikeuden periaate . . . . . . . . . . . . . . . . . . 12

4 Identiteetinhallinta 134.1 Paikallinen identiteetti . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Verkkoidentiteetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Yhdistetty identiteetti . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Globaali verkkoidentiteetti . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Pääsynhallinta 205.1 Reference monitor -malli . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Harkinnanvarainen pääsynhallinta (DAC) . . . . . . . . . . . . . . . . 215.3 Pakollinen pääsynhallinta (MAC) . . . . . . . . . . . . . . . . . . . . 22

5.3.1 Bell-LaPadula -malli (BLP) . . . . . . . . . . . . . . . . . . . 235.3.2 Biba -malli . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.4 Roolipohjainen pääsynhallinta (RBAC) . . . . . . . . . . . . . . . . . 245.4.1 Roolien määrittely ja hallinta . . . . . . . . . . . . . . . . . . 26

6 Tapaustutkimus: PääsynhallintamenetelmätIT-ulkoistuspalveluntarjoajayrityksessä 276.1 Pääsynhallinta palvelutoimintona ja käytetyt työkalut . . . . . . . . . 27

6.1.1 Check In Request (CIR) . . . . . . . . . . . . . . . . . . . . . 286.1.2 Access Request Approval Process (ARAP) . . . . . . . . . . . 28

6.2 Identiteetinhallintamenetelmät . . . . . . . . . . . . . . . . . . . . . . 29

vi

6.3 Pääsynhallintamenetelmät . . . . . . . . . . . . . . . . . . . . . . . . 306.4 Prosessi ja osapuolet . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.5 Pyyntöjen määrät, läpivientiaika ja käytetty aika . . . . . . . . . . . 32

6.5.1 Pyyntöjen määrät . . . . . . . . . . . . . . . . . . . . . . . . . 326.5.2 Pyyntöjen läpivientiaika . . . . . . . . . . . . . . . . . . . . . 336.5.3 Pyyntöihin käytetty aika . . . . . . . . . . . . . . . . . . . . . 34

6.6 Pyyntöjen toteutus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.7 Havaitut ongelmakohdat työkaluissa . . . . . . . . . . . . . . . . . . . 366.8 Yhteenveto tapaustutkimuksesta . . . . . . . . . . . . . . . . . . . . . 39

7 Pääsynhallinnan toteutusehdotus 407.1 Toteutuksen vaatimusmäärittely . . . . . . . . . . . . . . . . . . . . . 407.2 Pääsynhallinta palvelutoimintona . . . . . . . . . . . . . . . . . . . . 427.3 Käyttöoikeuspyyntöjen prosessikuvaus . . . . . . . . . . . . . . . . . 457.4 Identiteetinhallintamenetelmät . . . . . . . . . . . . . . . . . . . . . . 477.5 Pääsynhallintamenetelmät . . . . . . . . . . . . . . . . . . . . . . . . 487.6 Roolien määrittely . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.7 Työkalun määrittely . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.7.1 DirX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.7.2 IAM-työkalun toiminnallisuuden määrittely . . . . . . . . . . 507.7.3 Oikeuksien provisiointi . . . . . . . . . . . . . . . . . . . . . . 53

8 Arviointi, yhteenveto ja jatkotutkimus 568.1 Arviointi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.2 Yhteenveto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608.3 Kehitysehdotukset ja jatkotutkimus . . . . . . . . . . . . . . . . . . . 61

Viitteet 63

Liite A 66

A Roolitietojen keräämiseen käytetty kaavake 66

Liite B 68

B Vaatimusmäärittely pääsynhallinnan toteutusehdotukselle 68

vii

Lyhenteet ja termit

Lyhenteet

ABAC Attribute Based Access Control, ominaisuusperusteinenpääsynhallinta

ARAP Access Request Approval Process, Atos IT Solutions and Services Oy:nsisäinen käyttöoikeuksien hakemiseen tarkoitettu sovellus

BLP Bell-LaPadula -malliCIR Check In Request, Atos IT Solutions and Services Oy:n sisäinen

käyttöoikeuksien hakemiseen tarkoitettu sovellusCMDB Con�guration Management Database, kon�guraatiotietokanta,

joka sisältää IT infrastruktuurin komponentit ja niidenkon�guraatiotiedot

CMweb Change Management web console, Atos IT Solutions and Services Oy:nsisäinen muutospyynnöille tarkoitettu konsoli

COBIT Control Objectives for Information and related Technology, sisältääteollisuuden parhaita käytäntöjä ja viitekehyksiä yleisiinICT-prosesseihin

DAC Discretionary Access Control, harkinnanvarainen pääsynhallintaDSD Dynamic Separation of Duties, dynaaminen tehtävien eriyttäminenHR Human Resources, henkilöstöhallinto, joka vastaa yrityksen

erilaisista henkilöstöön liittyvistä käytännön tehtävistä sekälakisääteisistä asioista

IAM Identity and Access Management, identiteetin- ja pääsynhallintaICT Information and Communication Technology, tieto- ja

viestintätekniikkaISO International Organization for Standardization, kansainvälinen

standardisoimisjärjestöIT Information Technology, tietotekniikkaITIL Information Technology Infrastructure Library, kokoelma teollisuuden

parhaita käytäntöjä IT-palveluiden hallintaan ja johtamiseenKPI Key Performance Indicator, suorituskykyilmaisin, jolla

arvioidaan tietyn aktiviteetin toiminnallisuuttaLDAP Lightweight Directory Access Protocol, hakemistopalveluiden käyttöön

tarkoitettu verkkoprotokollaOLA Operational Level Agreement, operatiivisen tason sopimus,

joka määrittelee sisäisten tukiryhmien väliset riippuvuussuhteet jaosapuolten vastuualueet, mukaanlukien prosessit ja aikataulut

RBAC Role Based Access Control, rooliperusteinen pääsynhallintaSLA Service Level Agreement, palvelutasosopimus on osa

palvelusopimusta, jossa määritellään palvelulle tietytvaatimustasot, kuten palveluaika tai -suorituskyky

viii

SOA Service Oriented Architecture, palvelukeskeinen arkkitehtuurion järjestelmien kehityksessä ja ohjelmistotekniikassa käytettyjoustava suunnitteluperiaate, jossa järjestelmien toiminnot japrosessit ovat suunniteltu toimimaan itsenäisesti ja käytettäväksiavoimesti standardoitujen rajapintojen kautta

SoD Separation of Duties, tehtävien eriyttäminenSPOC Single Point of Contact, keskitetty yhteydenottopiste,

jonne määritetty viestintä ohjataanSSD Static Separation of Duties, staattinen tehtävien

eriyttäminenSSO Single Sign-On, kertakirjautuminen on menetelmä jolla

toteutetaan pääsy useisiin kohdejärjestelmiin käyttäjän yhdelläautentikoinnilla. Kertakirjautumisen tarkoituksena on vähentäätoistuvia autentikointeja käytettäessä samaa käyttäjätunnustakäyttäviä palveluita.

TCB Trusted Computing Base, luotettu tietojenkäsittelypohja,jolla tarkoitetaan tietokonejärjestelmään kuuluvista laitteistamuodostuvaa kokonaisuutta, joka yhdessä toteuttaa turvapolitiikan

URI Uniform Resource Identi�er, merkkijono, jollatunnistetaan identi�oitavissa oleva internet-resurssi

ix

Termit

Bottom-up menetelmä Roolien määrittämisen menetelmä, jossa roolitmääritellään olemassa oleviin käyttöoikeustietoihinperustuen

Haavoittuvuus (engl. Vulnerability) Heikkous tai virhekohdejärjestelmässä, jota voi hyödyntää yksi taiuseampi uhka

Identiteetti (engl. Identity) Aktiivinen itsenäinen kokonaisuus,joka voi olla fyysinen henkilö, kohdejärjestelmä taiverkkolaite, tai ohjelmallinen, joka suorittaa tiettyjätoimintoja. Henkilön kohdalla identiteetillätarkoitetaan niitä tietoja, jotka erottavat yksilön jatodentavat hänen asemansa organisaatiossa.Identiteetti on aina yksilöllinen.

Kohdejärjestelmä (engl. Target system) Kohde tai palvelu, johon voidaananoa oikeutta

Kontrolli (engl. Control) Tarkoittaa riskien hallinnan keinoja,sisältäen politiikan, toimintatavat, ohjeistuksen,käytännöt ja organisaation rakenteet, jotka voivatolla hallinnollisia, teknisiä, johdollisia taioikeudellisia.

Käyttöoikeus/oikeus (engl. Privilege/Access) Todelliset asetukset,jotka mahdollistavat käyttäjälle palvelun käytöntai pääsyn kohdejärjestelmään. Tyypillisiäpääsyoikeusasetuksia ovat lukeminen, kirjoittaminen,suorittaminen, muuttaminen ja poistaminen.

Neljän silmän periaate Tietoturvaperiaate, jossa hyväksynnän tulee ainatapahtua kahden henkilön toimesta

Partneri/kolmas osapuoli (engl. Third party/Partner) Henkilö, organisaatio taitaho, joka tekee yhteistyötä tai osallistuu jollakintavalla organisaation liiketoimintaan, sentuottamiseen tai tukemiseen

Politiikka (engl. Policy) Virallisesti ilmaistu menettelytapa,tarkoitus ja suunta

Pro�ili (engl. Pro�le) Identiteetin digitaalinen esitysmuoto,viitaten usein vain tiettyyn käyttäjään. Pro�ili voiolla myös esitys tietyn tyyppisestä käyttäjämallista,jolloin pro�ili voidaan siirtää käyttäjältä toiselle.

Prosessi (engl. Process) Suoritettavien toimenpiteiden sarja,jotka tuottavat määritellyn lopputuloksen. Prosessissatapahtumat ja suoritteet toistuvat samankaltaisinajostain määritellystä näkökulmasta tarkasteltuna.

Provisiointi Käyttöoikeuksien luominen tai välittäminenkohdejärjestelmiin

x

Pääsynhallinta (engl. Access Management) Tässä diplomityössäpääsynhallinnalla tarkoitetaan käyttäjien pääsy- jakäyttöoikeuksien hallintaa

Pääsyoikeus/valtuus (engl. Permission) Palvelun toimintojen ja tietojentaso ja laajuus, joita käyttäjällä on valtuus käyttää

Riskanalyysi (engl. Risk analysis) Systemaattinen tiedon kerääminenja tarkastelu, tavoitteena tunnistaa ja arvioida riskienlähteet ja vaikutukset

Riski (engl. Risk) Tapahtuman todennäköisyyden ja negatiivisenseurauksen yhteisvaikutusta

Rooli Työtehtävä, johon on kuvattu joukko pääsy- jakäyttöoikeuksia, joita tarvitaan työn suorittamiseen

Service Desk Yrityksen IT-palveluiden keskitetty yhteydenottopiste(SPOC), jonka tarkoituksena on vastaanottaa käyttäjienja työntekijöiden tietoteknisiä palvelupyyntöjä jakäynnistää niiden käsittely

SharePoint Microsoft tiedonhallintaratkaisu, joka tarjoaa mm.keskitetyn ja ryhmätyön mahdollistavandokumenttien hallinnan yrityksen web-sivustoilla

Tiketöintijärjestelmä Palveluntuottajan palvelupyyntöjen hallintajärjestelmäTop-down menetelmä Roolien määrittämisen menetelmä, jossa

roolimääritelmät perustuvat yrityksenorganisaatiokaavioihin ja prosessikuvauksiin

Uhka (engl. Threat) Mahdollinen epätoivottu tapahtuma, jokavoi aiheuttaa haittaa yhteen tai useampaankohdejärjestelmään tai organisaatioon

1 Johdanto

Miksi pääsynhallinta on tärkeää yrityksille? Otetaan esimerkki lentokentästä, jossafyysinen pääsynhallinta, eli kulunvalvonta, on tärkeä turvallisuustekijä. Lentokentäl-lä ei voida sallia jokaisen pääsevän lentokentän kaikille alueille, vaan pääsy alueilleon rajoitettu käyttötarkoitusten ja käyttäjäkunnan mukaan. Pääsyoikeudet perustu-vat lentokentän ja siellä toimivien yritysten turvapolitiikkoihin ja sääntöihin, joistapoikkeaminen vaarantaisi paitsi yritysten liiketoiminnan, myös koko käyttäjäkunnanturvallisuuden. Samaan tapaan tietojärjestelmien pääsynhallinta on tapa hallita jaturvata liiketoiminnan kannalta tärkeät tietopääomat, -järjestelmät ja niiden käyt-täjät.

Organisaatioissa tietojärjestelmien käyttäjäkunta voi olla hyvinkin suuri, tieto-järjestelmiä paljon ja käyttöaste korkea. Tämä asettaa omanlaisiaan haasteita pää-synhallinnan suunnitteluun ja toteutukseen: tietoturvan näkökulmasta pääsynhal-linnan tulee perustua sääntöihin sekä olla hallittavissa ja auditoitavissa. Organisaa-tion etuja vuorostaan ovat nopea ja tehokas pääsynhallinta sekä kulujen pitäminenmahdollisimman alhaisina. IT-ulkoistuspalveluita tarjoavassa yrityksessä tulee lisäk-si ottaa huomioon käyttäjäkunnan ja ylläpidettävien järjestelmien monimuotoisuusja niissä tapahtuvien muutosten tiheys.

Diplomityö on tehty Atos IT Solutions and Services Oy yritykselle. Diplomityös-sä esitellään pääsynhallinta osana IT palvelutoimintaa ja tutustutaan erilaisiin pää-synhallintamenetelmiin. Diplomityössä käydään läpi tapaustutkimuksena yrityksenpääsynhallinnan nykytilan toteutus ja siinä käytetyt menetelmät. Lisäksi esitellääntoteutusehdotus kustannustehokkaasta ja skaalautuvasta pääsynhallintaratkaisusta,joka soveltuisi ja jolla voitaisiin tehostaa käyttöoikeuksienhallintaa yrityksessä. Osa-na diplomityötä suunniteltiin ITILv3:n mukainen pääsynhallintaprosessi ja roolipe-rustaista pääsynhallintaa tukeva roolimäärittely.

1.1 Tausta

Atos IT Solutions and Services Oy on IT-palveluita maailmanlaajuisesti tarjoa-va yritys, joka keskittyy erityisesti IT-ulkoistuspalveluiden tarjoamiseen. Yrityk-sen tarjoamat IT-palvelut perustuvat kansainvälisesti tunnettuihin ITIL- ja CO-BIT -käytäntöihin. Yrityksen koko IT-palvelutoiminnalle on myönnetty ISO 9001laadunhallinnan-, ISO/IEC 20000 palveluidenhallinnan- ja ISO/IEC 27001 tietotur-vahallinnan serti�kaatit, joilla vahvistetaan sitoutumista laatuun ja sen jatkuvaankehittämiseen. Myös yrityksen sisäiset toimintatavat ja prosessit pyritään kehittä-mään alan parhaisiin käytäntöihin perustuen.

2

1.2 Tutkimusongelma

Usein pääsynhallinta tarvitsee toteuttaa käyttäjäkunnalle, jolle voidaan määritelläselkeät roolit ja oikeustasot, ja joka kohdistuu rajattuun määrään erilaisia kohde-järjestelmiä tai palveluita. IT-ulkoistuspalveluita tarjoavassa yrityksessä pääsykoh-teita ovat paitsi yrityksen sisäiset kohdejärjestelmät ja palvelut myös hallinnoidutasiakasjärjestelmät. Kohdejärjestelmien käyttäjiä voivat olla yrityksen omat sisäisettyöntekijät sekä ulkoiset työntekijät, kuten partnerit ja asiakkaan työntekijät. Käyt-täjäkunnan monimuotoisuus tekee pääsynhallinnasta erityisen tärkeää tietoturvannäkökulmasta: käyttäjien tunnistamisella ja pääsyn rajaamisella oikealle käyttäjä-ryhmälle pyritään vähentämään yritykseen ja sen tietoturvaan kohdistuvia uhkia.

Atos IT Solutions and Services Oy:n nykyinen pääsynhallinta on toteutettu kah-della eri työkalulla, joissa molemmissa on omat heikkoutensa. Haettavia oikeuksia eiole tarkasti jaoteltu työkalujen välille, vaan joitakin oikeuksia voi hakea molemmil-la työkaluilla ja joitakin oikeuksia puuttuu kummastakin. Loppukäyttäjät kokevatmolemmat työkalut vaikeiksi käyttää, eivätkä erota kumpaa työkalua kuuluisi käyt-tää. Tämä on johtanut osittain siihen, että joitain oikeuksia haetaan suoraan pal-velupyyntöinä tiketöintityökalulla, jolloin kirjanpito jaetuista oikeuksista jää puut-teelliseksi. Lisäksi yhtenäinen pääsynhallinnan malli ja käsitteellinen prosessikuvauspuuttuvat.

Käyttöoikeuspyyntöjen läpivientiaika pyyntöjen määrään nähden koetaan yri-tyksessä korkeaksi. Uusi työntekijä, tai työntekijä jonka työnkuva vaihtuu, joutuuusein odottamaan pääsyoikeuksia, joita hän tarvitsee uuden työnkuvansa suoritta-miseen. Tapaustutkimuksella on tarkoitus kartoittaa nykyisen pääsynhallinnan to-teutus ja tehokkuus sekä arvioida miten hyvin se vastaa yrityksen liiketoiminnallisiinvaatimuksiin.

Tyypillisesti IT-ulkoistuspalveluita tarjoavan yrityksen tuotantotiimeissä työs-kentelevillä työntekijöillä on hyvin samanlaiset oikeudet keskenään tiimin sisällä.Rooliperustaisia käyttöoikeuksia ei ole yrityksessä määritelty ja käyttöoikeuksia hae-taan käyttäjille yksitellen tarpeen mukaan. Rooliperustainen pääsynhallintamallimahdollisesti vähentäisi yksittäisten käyttöoikeuspyyntöjen määrää ja lisäisi oikeuk-sien jaon tehokkuutta ja hallittavuutta.

1.3 Arviointikriteeri

Pääsynhallintamenetelmien, siinä käytettävien työkalujen ja toteutusvaihtoehtojenarvioinnissa käytettiin alla lueteltuja arviointikriteerejä. Kriteereiden avulla voidaanolettamuksiin ja tulkintoihin perustuenkin arvioida ratkaisun sopivuutta ja kannat-tavuutta IT-ulkoistuspalveluita tarjoavan yrityksen toimintaan ja sen hallinnoimiinIT-ympäristöihin.

• Toteutuskelpoisuus: toteutuksen vaatimat henkilö- ja aikaresurssit sekä inves-

3

toinnit tulevat olla yrityksen kokoon ja liikevaihtoon nähden kohtuulliset.

• Taloudellinen kannattavuus: ratkaisun tulee tuottaa yritykselle säästöjä ja li-säarvoa verrattaessa olemassa olevaan ratkaisuun.

• Ylläpidettävyys ja käytettävyys: toteutus ei saa olla liian monimutkainen työ-kalun ylläpitäjälle eikä loppukäyttäjälle

• Turvallisuus: toteutus ei saa häiritä käyttäjien päivittäisiä työtehtäviä tai hai-tata yrityksen IT-ympäristöjä. Sen tulee noudattaa yrityksen tietoturvakäy-täntöjä ja käyttöoikeushallinnan osalta parantaa yrityksen tietoturvapolitiikantoteutumista.

• Skaalautuvuus: toteutuksen tulee ottaa huomioon käyttäjäkunnan ja ylläpidet-tävien järjestelmien monimuotoisuus ja määrä sekä niissä tapahtuvien muu-tosten yleisyys.

• Serti�oitavuus: toteutuksen tulee olla linjassa yleisesti hyväksyttyjen alan par-haiden käytäntöjen kanssa.

1.4 Diplomityön rakenne

Tämä diplomityö koostuu kahdeksasta kappaleesta. Ensimmäinen kappale toimiijohdantona aiheeseen esitellen aiheen taustan ja aiheeseen liittyvän tutkimusongel-man sekä toteutuksen arviointikriteerin. Kappaleet 2, 3, 4 ja 5 käsittelevät tutki-musongelmaan liittyvää teoriaa ja taustatietoa.

Kappaleessa 2 käydään läpi, mitä palvelulla ja palvelunhallinnalla tarkoitetaanja mikä merkitys sillä on IT palveluorganisaatiossa. Lisäksi keskustellaan toimin-taprosessien serti�oinnin tarpeellisuudesta yrityksille. Kappaleessa 3 käydään läpitietoturvan ja tietoturvan hallinnan merkitystä yrityksille. Tietoturvalle asetetaanusein tavoitteita, jotka tulee saavuttaa ja tietoturvanhallinta kuvataan jatkuvak-si palveluntoimitusprosessiksi. Kappaleessa 4 käydään läpi, miten tietojärjestelmiinliittyviä identiteettejä hallinnoidaan ja miten eri hallintamenetelmät eroavat toi-sistaan. Kappaleessa 5 käydään läpi, mitä tarkoitetaan pääsynhallinnalla. Pääsyn-hallintamenetelmän valintaan vaikuttaa oleellisesti se, mitä sillä halutaan saavuttaa.

Kappaleessa 6 käydään tapaustutkimuksena läpi, miten pääsynhallintamenetel-mät on toteutettu IT-ulkoistuspalveluita tarjoavassa yrityksessä. Kappaleessa käy-dään läpi yrityksen pääsynhallinnassa käytetyt menetelmät ja työkalut sekä pyritäänosoittamaan havaitut ongelmakohdat.

Kappale 7 esittelee toteutusehdotuksen siitä, miten pääsynhallinta voitaisiin to-teuttaa IT-ulkoistuspalveluita tarjoavassa yrityksessä. Pääsynhallinta pyritään ku-vaamaan siten, että se voitaisiin määrittää yhdeksi palvelutoiminnoista. Toteutuseh-dotuksen tavoitteena on tarjota tehokas tapa hallinnoida ja toteuttaa käyttöoikeus-

4

pyyntöjä ja osaltaan lisätä yrityksen tietoturvaa.

Kappale 8 sisältää toteutusehdotuksen arviointiosuuden ja yhteenvedon tutki-muksesta. Tuloksia vertaillaan asetettuihin arviointikriteereihin ja tapaustutkimuk-sesta saatuihin tuloksiin. Lisäksi käydään läpi kehitysehdotukset ja jatkotutkimus.

5

2 Palvelunhallinta IT palveluorganisaatiossa

Palvelulla voidaan tarkoittaa monia eri asioita, ja sen tarkoitus riippuu vahvastiasiayhteydestä. Joillekin palvelu tarkoittaa asiakaspalvelua ja joillekin logistista taitaloudellista toimintaa. Tässä diplomityössä palvelulla tarkoitetaan yhtä tai useam-paa vuorovaikutusaktiviteettia asiakkaiden ja palveluresurssien välillä. Palveluakti-viteeteilla pyritään vastaamaan asiakkaan pyyntöihin ja tarjoamaan niitä tuloksia,joita asiakas haluaa saavuttaa. Lisäarvoa pyritään tuottamaan vapauttamalla asia-kas riskeistä ja kustannuksista, joita tulosten tuottaminen edellyttää, laskuttamallaasiakasta vain palvelun käytöstä. Palvelun tarjoamisen yhteydessä asiakkaalla tar-koitetaan osapuolta, joka pyytää palvelua, ottamatta kantaa onko hän organisaationsisäinen henkilö, partneri tai ulkoinen asiakas. [7, s. 9]

Palvelun tuottamiseen on usein määritelty prosessi, jonka mukaan palvelua tuo-tetaan. Palvelun tuottaminen lähtee liikkeelle syötteestä (engl. input) ja päättyytulokseen (output). Asiakas ei välttämättä näe tai koe koko palvelun tuottamiseenvaadittua työmäärää ja prosessia vaan ainoastaan toiminnot ja palautteet, joihinhän on osallisena sekä suorittamiseen kuluneen ajan ja saadut tulokset. Kuvassa 1on kuvattu etualalle asiakkaan näkemä ja kokema osa palvelusta ja taka-ala pitääsisällään palvelun tuottamiseen liittyviä työtehtäviä ja prosesseja, joita asiakas eitavallisesti näe ja koe. Palvelun prosessin ja asiakkaan kokemuksen päällekkäisyysyhdistettynä IT-palveluiden abstraktiin luonteeseen tekevät palveluiden hallinnastaerityisen haasteellista, jännittävää ja ajoittain jopa turhauttavaa. Palveluiden suun-nittelussa ja kehityksessä tulee kiinnittää huomiota prosessin tehokkuuden lisäksimyös asiakkaan saamaan kokemukseen, koska sillä on suuri vaikutus asiakkaan saa-maan laatuvaikutelmaan koko organisaatiosta. Palvelun kannalta asiakkaaksi lue-taan osapuoli, joka joko käyttää palvelua tai vastaanottaa sen lopputuleman. Os-apuoli voi olla organisaation sisäinen tai ulkoinen. Tässä diplomityössä asiakkaallatarkoitetaan ensisijaisesti osapuolta, joka ostaa palvelua palveluntarjoajayritykseltä.[7, s. 10]

6

Kuva 1: Palvelutoiminta. [7, s. 11]

Palvelunhallinta (engl. Service Management) on kokonaisuus organisatorisia eri-koiskykyjä tarjota asiakkaalle arvoa palveluiden muodossa. Kyvyt ovat toimintoja japrosesseja, joilla hallitaan palveluita niiden elinkaaren ajan keskittyen erityisesti pal-veluiden strategiaan, suunnitteluun, siirtymävaiheeseen, käyttöön ja jatkuvaan pa-rantamiseen. Kyvykkyydet myös ilmaisevat palveluorganisaation kapasiteettia, pä-tevyyttä ja luottamuksellisuutta. Ilman näitä kyvykkyyksiä ja taitoa muuttaa orga-nisaation resursseja arvoa tuottaviksi palveluiksi, palveluorganisaatio on ainoastaanjoukko resursseja, joilla itsellään on suhteellisen alhainen todellinen arvo asiakkaal-le. [2, s. 11]

Palvelunhallinnan tärkeys korostuu IT-palveluita tarjoavassa organisaatiossa, sil-lä tarjottujen palveluiden määrän ollessa suuri toimintojen toistettavuus, tehok-kuus, standardien noudattaminen ja skaalautuvuus vaikuttavat oleellisesti palve-luiden kustannusten ja laadun hallintaan [17]. IT-palveluntarjoajan liiketoiminnanvaatimukset usein edellyttävät palvelujen toimittamisen olevan kustannustehokasta,ja liiketoiminnan jatkuvuuden kannalta palveluiden laadun tulee täyttää asiakkai-den asettamat kriteerit [9, s. 1].

Palvelunhallinnan päätavoitteita ovat [8, s. 4]:

• Sovittaa IT-palvelut yrityksen oman liiketoiminnan sekä asiakkaiden nykyisiinja tuleviin tarpeisiin

• Parantaa tuotettujen IT-palveluiden laatua ja asiakkaan saamaa kokemustapalvelusta

• Vähentää palvelun ylläpitämiseen vaadittavia kustannuksia

ISO/IEC 20000-1:2005 määrittelee kuvan 2 mukaisesti palvelunhallintaprosessitviiteen kategoriaan [9, s. 1]:

7

1. Palveluntoimitusprosessit (engl. Service Delivery Processes)

2. Yhteysprosessit (engl. Relationship Processes)

3. Ratkaisuprosessit (engl. Resolution Processes)

4. Julkaisuprosessit (engl. Release Processes)

5. Kontrolliprosessit (engl. Control Processes)

Kuva 2: Palvelunhallintaprosessit. [9, s. 1]

Tässä diplomityössä tarkasteltu pääsynhallinta on vahvasti yhteydessä tietotur-vanhallintaprosessiin. Tietoturvan hallintaprosessi on ISO/IEC 20000-1:2005:n mu-kaan yksi palveluntoimitusprosesseista. Pääsynhallintaprosessilla on tarkoitus luodalisäarvoa yritykselle tarjoamalla keskitetysti hallittuja ja kustannustehokkaita pää-syn anomis- ja toimitusaktiviteetteja [1, s. 68].

2.1 Serti�oinnin tarpeellisuus

Organisaation rakennettua toimintaprosessinsa ja -politiikkansa perustuen yleises-ti hyväksyttyihin alan parhaisiin käytäntöihin (ITIL v3, COBIT Guidance to Ac-hieve Control Objectives for Successful IT Governance), organisaatio voi hakeamuun muassa ISO 9001 laadunhallinnan-, ISO/IEC 20000 palveluidenhallinnan- jaISO/IEC 27001 tietoturvahallinnan standardien mukaisia serti�ointeja koko toimin-nalleen tai jollekin toiminnan osa-alueelle. [14]

8

Standardien tarkoitus on mahdollistaa systemaattinen tapa ohjata ja hallita or-ganisaation toimintoja ja prosesseja. Standardien noudattaminen auttaa organisaa-tiota paremmin ymmärtämään ja täyttämään asiakkaiden ja muiden sidosryhmientarpeet ja odotukset sekä valvomaan ja kehittämään toimintansa laadun- ja tieto-turvanhallintajärjestelmiä. [18]

Toiminnan serti�ointi on kolmannen osapuolen antama pätevä todiste, joka osoit-taa yrityksen sitoutumisen toimimaan vaatimusten mukaisesti [19]. Se lisää asiak-kaiden ja yhteistyökumppaneiden luottamusta organisaatioon ja voi vaikuttaa posi-tiivisesti organisaation liiketoiminnan jatkuvuuteen [3, s. 11-12].

9

3 Tietoturva

Organisaatioiden tärkeimpiä pääomia ovat tieto ja tietojärjestelmät [4, viii]. Tietoja tiedon hallinta vaikuttavat oleellisesti liiketoiminnan jatkuvuuteen ja kasvuun,sillä tietoon kohdistuvalla rikoksella tai vahingolla voi olla organisaation tulevaisuu-den kannalta suuremmat vaikutukset kuin etukäteen tulee ymmärtäneeksi [3, s. 1].Tietoturvan vaarantuessa vaikutukset ulottuvat liiketoiminnan kilpailukykyyn, ta-loudelliseen kannattavuuteen ja organisaation maineeseen [3, s. 1].

Tieto voi esiintyä monessa muodossa. Se voi olla esimerkiksi paperille tulostet-tua, keskustelussa puhuttua, videolla näytettyä, postissa lähetettyä tai sähköiseenjärjestelmään kuten tietokantaan tallennettua. Riippumatta tiedon esitys- ja tallen-nusmuodosta, tiedon tulee olla aina asianmukaisesti suojattu. [4, viii]

Tietoturvan tärkeys on korostunut erityisesti liiketoimintaympäristöjen liitän-töjen ja tietoturvauhkien määrän kasvaessa tietoyhteiskunnassa [4, viii]. Organi-saatioiden valveutuneisuus tietoturvauhkia kohtaan on lisääntynyt ja tietoturva onotettu huomioon myös monissa standardointielimissä [3, s. 1]. Noudattamalla tie-toturvastandardeja organisaatiot pyrkivät luomaan itselleen tietoturvan hallintajär-jestelmän. Tietoturvan hallinnan tavoitteena on auttaa organisaatiota suojaamaansen liiketoiminnan kannalta tärkeät tietopääomat ja järjestelmät [3, s. 1] [4, viii].Tietoturvassa on pohjimmiltaan kyse riskien hallinnasta ja niiden arvioinnista. Suo-jattavalle tiedolle on osattava määritellä arvo, valittava hyväksyttävä riskitaso javerrattava arvoa ja riskitasoa tietoturvainvestointeihin [6, s. 8].

Yksi yleisesti käytössä olevista tietoturvastandardeista on ISO/IEC 27002:2005Information technology - Security techniques - Code of practice for information secu-rity management, joka on kehitetty vuonna 1995 julkaistusta BS7799 tietoturvas-tandardista [4, iii]. ISO/IEC 27002:2005 tietoturvastandardi tarjoaa yleisiä periaat-teita ja toimintamalleja organisaation tietoturvan hallinnan aloittamiseen, toteut-tamiseen, huoltamiseen ja parantamiseen [4, s. 1]. Standardi koostuu kokoelmastahyväksi havaittuja toimintamalleja ja -tapoja ja se keskittyy yleiseen liiketoiminnanturvaamiseen tähtäävään tietoturvaan [4, s. 1].

3.1 Tietoturvan hallinta

Tietoturvan toteutuksen tulee aina perustua tietoturvapolitiikkaan, jonka laadinnas-sa tulisi käyttää riskianalyysin tuloksia [4, s. 7]. Tietoturvapolitiikan tarkoituksenaon tarjota ohjausta ja tukea koko organisaatiolle sekä sen hallinnolle ja johdolle toi-mia liiketoiminnan vaatimusten ja asianmukaisten lakien ja määräysten mukaisesti[4, s. 7]. Organisaation johdon tulee asettaa selkeä poliittinen suunta, joka tukeeliiketoiminnan tavoitteita ja joka osoittaa sitoutumista tietoturvan ja sen politiikanylläpitämiseen koko organisaatiossa [4, s. 7]. Tietoturvapolitiikassa määritellään käy-tännön tietoturvan hallinnan vastuualueet sekä raportointitoimenpiteet, joita tulee

10

noudattaa havaittaessa mahdollisia tietoturvarikkomuksia [3, s. 4].

Tietoturvan hallinnan prosessin päämääränä on yhdenmukaistaa linja tietotek-niikan tietoturvan ja yritystietoturvan välillä ja taata tietoturva, joka on tehokkaastihallittavissa kaikissa palveluissa ja palvelunhallinta toiminnoissa. Tietoturvan hal-linta toimii osana organisaation hallintoa, jonka tarkoituksena on tarjota strategisianeuvoja tietoturvatoiminnoille ja varmistaa toimintojen tavoitteiden saavuttaminen.Tietoturvan hallinta pyrkii takaamaan, että tietoturvariskit tunnistetaan ja niihinreagoidaan asianmukaisesti ja yrityksen tietoresursseja käytetään vastuullisesti. [2,s. 141]

Tietoturvan hallinta on saavutettavissa ottamalla käyttöön asianmukaiset toi-mintatavat sisältäen politiikan, prosessit, käytännöt, organisaatiorakenteet ja ohjelmisto-ja laitteistotoiminnot [2] [4]. Tietoturvan hallinnan aloittamisen tueksi ja ohjeistuk-seksi on määritelty erinäisiä standardeja, viitekehyksiä ja parhaita käytäntöjä sisäl-täviä julkaisuja. Tällaisia standardeja ja julkaisua ovat muun muassa:

• Standardi ISO 27002:2005, joka tarjoaa yleisiä periaatteita, toimintamalleja jakäytäntöjä tietoturvan hallinnan käyttöönottoon. [4, s. 1]

• Standardi ISO 27001:2005, joka määrittelee vaatimuksia dokumentoidun tie-toturvan hallinnan perustamiseen, toteuttamiseen, käyttämiseen, valvomiseen,arvioimiseen ja parantamiseen. [5, s. 1]

• ITIL v3 Service Design, maailmanlaajuisesti tunnettu prosessikehys, joka tar-joaa laajan kokoelman käytäntöjä IT-palveluiden kehitykseen, hallintaan jajohtamiseen. [2]

Organisaation valveutuneisuus olemassa olevista tietoturvista on yksi tärkeim-mistä tietoturvallisuuden lisäämisen ajajista ja tietoturvan hallinnon käyttöönotta-misen syistä [3, s. 1]. Useimmille organisaatioille tietoturvatavoitteiden saavuttami-nen edellyttää tiettyjen ehtojen täyttymistä [2, s. 141]:

• Saatavuus: Tieto on saatavilla ja käytettävissä aina tarvittaessa, ja järjestelmäkykenee asianmukaisesti torjumaan ja toipumaan hyökkäyksistä ongelmatilan-teiden ehkäisemiseksi.

• Luottamuksellisuus: Tieto on noudettavissa ja luovutetaan vain heille, joillaon oikeus tietoon.

• Eheys: Tieto on yhtenäistä ja täsmällistä, sekä suojattu epätoivotulta muok-kaukselta.

• Aitous ja kiistämättömyys: Yrityksen liiketoimintatapahtumat ja tiedon vaih-taminen erilaisten osapuolten välillä ovat luotettavia ja voidaan todentaa jäl-kikäteen.

11

Tietoturvan hallintaprosessin voidaan kuvata koostuvan kuvan 3 mukaisesti vii-destä osasta [2, s. 144]:

1. Kontrolli: määrittelee vastuualueet, luo ja hallinnoi dokumentaatioita, perus-taa hallinnollisen viitekehyksen organisaation tietoturvan hallinnalle.

2. Suunnittelu: suunnittelee ja suosittelee asianmukaisia turvatoimia, jotka pe-rustuvat organisaation asettamiin vaatimuksiin.

3. Käyttöönotto: varmistaa, että asianmukaiset menettelyt, työkalut ja kontrollitovat otettu käyttöön tukemaan tietoturvapolitiikkaa.

4. Arviointi: valvoo ja tarkistaa tietoturvapolitiikan ja -vaatimusten noudatta-misen palvelutason (SLA) ja operatiivisen tason (OLA) sopimuksissa, suorit-taa säännöllisiä tietoturvatarkastuksia tietojärjestelmiin ja tarjoaa tarvittaessatietoa ulkoisille tarkastajille ja valvojille.

5. Ylläpito: parantaa SLA ja OLA sopimuksissa olevia turvallisuuden kannaltatärkeitä asioita sekä tehostaa turvatoimenpiteiden ja kontrollien käyttöönot-toa.

Kuva 3: Tietoturvan hallinnan viitekehys. [2, s. 144]

3.1.1 Tehtävien eriyttäminen (SoD)

Tehtävien eriyttäminen (engl. separation of duties, SoD) on tietoturvaperiaate, jollapyritään estämään mahdollinen haitallinen toiminta kohdejärjestelmiin. SoD periaa-te on, ettei yhdelläkään yksittäisellä käyttäjällä olisi mahdollisuutta suorittaa kaik-kia toimenpiteitä itse tietyn kokonaisuuden sisällä. Esimerkiksi kaupankäyntiin tai

12

hankintaan liittyvissä ostoehdotuksissa käyttäjän ei tule pystyä itse hyväksymääntekemiään ostoehdotuksia. [22]

SoD voi olla joko staattinen tai dynaaminen [22]. Staattisessa tehtävien eriyttä-misessä (SSD) roolijäsenyydet määritellään toisensa poissulkevina [23]. Dynaaminentehtävien eriyttäminen (DSD) mahdollistaa päällekkäisyydet rooleissa, mutta rajoit-taa roolien toimintoja saman tapahtuman sisällä [23]. Esimerkiksi käyttäjä voi ollasekä ostoehdotuksen tekijän että hyväksyjän roolissa, mutta käyttäjää estetään hy-väksymästä hänen omia pyyntöjään [23].

3.1.2 Pienimmän oikeuden periaate

Pienimmän oikeuden periaate (engl. principle of least privilege) pyrkii estämään ta-hallisen ja tahattoman haitallisen toiminnan sallimalla käyttäjälle vain ne oikeudet,joita hän oikeasti tarvitsee työnsä suorittamiseen [22]. Pienimmän oikeuden peri-aatetta on verrattu tietoturvan kannalta yhtä merkittäväksi kuin tiedon eheyttä[24]. Pienimmän oikeuden periaate edellyttää käyttäjän työnkuvan kartoittamisenja työnsuorittamiseen tarvittavien oikeuksien vähimmäistasojen määrittämisen [22].

13

4 Identiteetinhallinta

Ihmisen työtehtävien automatisointi ja automatisoinnin kehitys tietojärjestelmis-sä on johtanut tarpeeseen kyetä esittämään identiteettejä, jotka käyttävät mallinaoikean elämän kokonaisuuksia ja vuorovaikutuksia. Tietojärjestelmissä identiteetinkäsitys ja käyttö kehittyi yksinkertaisesta tunnistemääritteestä tunnisteeksi, joka voiosoittaa useaan tuntomerkkiin ja niihin liitettyihin oikeuksiin, yleisesti viitaten pro-�iliin. Identiteetillä tarkoitetaan niitä tietoja, jotka erottavat yksilön ja todentavathänen asemansa organisaatiossa. Identiteetti on aina yksilöllinen. Pro�ililla tarkoi-tetaan identiteetin digitaalista esittämistä, viitaten usein vain tiettyyn käyttäjään,mutta se voi olla myös esitys tietyn tyyppisestä käyttäjämallista, jolloin pro�ili voi-daan siirtää käyttäjältä toiselle. [10, s. 40]

Identiteetinhallinta pyrkii vastaamaan haasteisiin, jotka liittyvät identiteettien japro�ilien määrän nopeaan kasvuun yritysten erilaisissa käyttöympäristöissä [11, s.3]. Tällaisia haasteita ovat muun muassa ristiviittaukset pro�ilien välillä, jotka edus-tavat samaa identiteettiä, sekä näiden pro�ilien ominaisuuksien välinen synkronointi[10, s. 40]. Lisäksi turvallisen tietoympäristön ylläpito ja käyttö perustuvat identi-teettien tunnistamiseen ja jaettujen käyttöoikeuksien hallintaan [10, s. 40]. Iden-titeetinhallinnassa tulee myös ottaa huomioon käytettävyyden säilyttäminen niinloppukäyttäjän kuin ylläpidon osalta [11, s. 3].

Identiteetinhallintaan liittyviä malleja löytyy kirjallisuudesta useita [10] [11] [28][29] [30]. Pääsääntöisesti tietojärjestelmissä identiteetinhallintamenetelmät voidaanjakaa identiteettien hallinnollisen ja toiminnallisen laajuuden mukaan [10, s. 51].Messaoud Benantar jakaa identiteetinhallintamenetelmät neljään luokkaan [10, s.51]:

1. Paikallinen identiteetti (engl. Local identity)

2. Verkkoidentiteetti (engl. Network identity)

3. Yhdistetty identiteetti (engl. Federated identity)

4. Globaali Web identiteetti (engl. Global Web identity)

4.1 Paikallinen identiteetti

Käyttäjärekisterin ylläpitämistä ja hallinnoimista keskitetysti yhdessä järjestelmäs-sä kutsutaan paikallisen identiteetin malliksi (engl. local identity) [10, s. 41]. Paikal-lisen identiteetin mallista käytetään myös nimeä eriytetyn identiteetin malli (engl.isolated identity) [28, s. 3]. Jokaiselle käyttäjälle, joka haluaa käyttää järjestelmää,tulee luoda yksilöllinen identiteetti käyttäjärekisteriin [10, s. 41] [28, s. 3]. Käyttä-järekisterissä käytettyjen identiteettien nimiavaruus on litteä, mistä johtuen kahtasamannimistä identiteettiä ei voi olla järjestelmässä, vaan jokaisen identiteettinimen

14

tulee olla uniikki [10, s. 41]. Identiteettien lisäykset ja poistot ovat erillisiä tapahtu-mia, joilla ei ole vaikutusta muihin identiteetteihin [10, s. 41]. Hallinnoitavat oikeu-det ovat kytköksissä oikeuksiin, joita käyttäjällä voi olla järjestelmän resursseihin[10, s. 41].

Keskitettyä käyttäjärekisteriä voi käyttää joko yksi (Kuva 4, kohta A) tai useam-pi kohdejärjestelmä (Kuva 4, kohta B). Jakamalla käyttäjärekisteri usean kohde-järjestelmän käytettäväksi pyritään lievittämään ylimääräistä järjestelmäkohtaistakäyttäjärekisterin hallintaa. [10, s. 42]

Kuva 4: Paikallinen identiteetti [10, s. 40]

Paikallisen identiteetin hyöty on sen yksinkertaisuus. Identiteetin luominen käyt-täjärekisteriin ja sen tunnistaminen ovat yksinkertaisia paikallisia prosesseja. Litteännimiavaruuden rakenne on samanlainen kuin datarakenteen, jossa tietueet ovat tau-lukossa. Yksinkertaisen rakenteen vuoksi tietueita voidaan helposti hallita yksittäi-sinä kokonaisuuksina. [10, s. 42]

Paikallisen identiteetin mallin ongelmat ovat sen rajoitettu skaalautuvuus [28, s.4], litteän nimiavaruuden rajoitukset sekä usean käyttäjärekisteriä käyttävän järjes-telmän hallinnolliset haasteet [10, s. 43]. Rajoitettu skaalautuvuus kapasiteetin osal-

15

ta tulee ilmeiseksi käyttäjien ja järjestelmässä käytettävien osajärjestelmien määränkasvaessa [10, s. 43]. Järjestelmän tulee pystyä tallentamaan ja ylläpitämään jokaisenjärjestelmän tietueen tiedot, jolloin tietueiden suuri määrä saattaa vaikuttaa kokojärjestelmän suorituskykyyn [10, s. 43]. Käyttäjäryhmien käyttäminen ei ratkaiseskaalautuvuuteen liittyviä ongelmia, sillä identiteetin määrittely tapahtuu kuiten-kin erillään riippumatta ryhmäjäsenyydestä [10, s. 43].

Litteän nimiavaruuden rakenne rajoittaa identiteettien nimeämisiä siten, ettäjokaisen identiteettinimen tulee olla uniikki, mikä johtaa usein siihen, että iden-titeettien nimet generoidaan järjestelmässä. Lisäksi paikallisen identiteetin mallissaidentiteetin käytön laajuus rajoittuu niihin kohdejärjestelmiin, joihin se on määritel-ty. Kohdejärjestelmien, jotka käyttävät omaa käyttäjärekisteriä (Kuva 4, kohta A),määrän kasvaessa, myös identiteetteihin liitettyjen järjestelmäkohtaiset salasanojenmäärä kasvaa. Tämä lisää käyttäjien muistikuormaa ja samalla heikentää palvelui-den tehokasta käyttämistä. [10, s. 43]

Salasanasynkronisointi on yksi vaihtoehto korvaamaan järjestelmäkohtaisia sa-lasanoja [10, s. 43]. Salasanasynkronoinnin idea on, että käyttäjällä on vain yksisalasana ja se synkronisoidaan käyttäjärekisterien välillä. Toisin kuin kertakirjau-tumismenetelmässä (SSO), salasanasynkronisointia käytettäessä käyttäjän tarvitseejokaiseen palveluun kirjautuessa syöttää aina salasana [10, s. 43]. Salasanasynkro-nisoinnin käyttöönotto on usein kuitenkin helpompaa kuin SSO:n, sillä se ei vaadisuuria muutoksia yrityksen olemassa oleviin tietoverkkorakenteisiin [10, s. 43]. Sala-sanasynkronoinnin haittana on käyttäjärekisterissä olevien muiden käyttäjätietojenyhteneväisyyden ylläpitäminen [10, s. 43]. Salasanasynkronointia vastaava toiminta-tapa on metaidentiteetti, jossa tietyt identiteettiin liitetyt jaetaan järjestelmien jakäyttäjärekisterien kesken [28, s. 6].

Toinen vaihtoehto on käyttää jaettua käyttäjärekisteriä usean kohdejärjestelmänkesken (Kuva 4, kohta B) [10, s. 44]. Kirjallisuudessa jaetun käyttäjärekisterin toi-mintatavasta käytetään myös nimeä yhteinen identiteetti (engl. common user iden-tity model) [28, s. 5]. Jaetun käyttäjärekisterin käyttämisen etuna salasanasynk-ronointiin verrattaessa on käyttäjätietojen eheys ja helppo ylläpidettävyys, muttakäyttäjämäärän ja rekisteriä käyttävien järjestelmien määrän kasvaessa suoritusky-ky voi osoittautua pullonkaulaksi [10, s. 44].

4.2 Verkkoidentiteetti

Tietoverkkojen ja hajautettujen tietojärjestelmien yleistyminen on johtanut verkkoi-dentiteetin mallin (engl. network identity) syntymiseen. Verkkoidentiteetin mallissaidentiteettiä ei autentikoida yksittäistä kohdejärjestelmää kohden, vaan autentikoin-ti tapahtuu tietoverkkoa kohden. Kun identiteetti on vahvistettu tietoverkkoa koh-den, verkkoon liitetyt resurssit ja palvelut ovat käytettävissä ilman, että identiteet-tiä tarvitsee erikseen vahvistaa. Verkkoidentiteetin laajuus on perinteisesti rajoitet-

16

tu yrityksen omaan verkkoon (Kuva 5, kohta A), mutta se on mahdollista laajentaamyös usean erillisen verkon tai yrityksen käyttöön (Kuva 5, kohta B). [10, s. 46]

Kuva 5: Verkkoidentiteetin malli [10, s. 46]

Tyypillinen esimerkki verkkoidentiteetistä on tietokoneen käyttöjärjestelmätun-nuksien käyttäminen verkkotunnuksina ja niiden hallinnointi esimerkiksi MicrosoftActive Directoryn avulla [31]. Active Directory toimii verkon identiteettikomponent-tina, sisältäen käyttäjätietokannan ja hakemistopalvelut sekä tiedot verkon resurs-seista [32]. Se mahdollistaa keskitetyn resurssien jakamisen käyttäjille ja sovelluksille[32].

Verkkoidentiteetti on tehokas tapa tarjota suuri määrä palveluita suurelle mää-rälle käyttäjiä. Verkkoidentiteetin ongelma on, että identiteettikohtaiset resurssien-käyttömahdollisuudet ovat usein todella suuret, jolloin myös tietoturvaan kohdistu-vien uhkien määrä kasvaa. Lisäksi jos identiteetin vahvistaminen onnistutaan ko-konaan kiertämään, saa pahantahtoinen käyttäjä mahdollisesti rajattoman pääsynkoko verkon resursseihin. [11]

17

4.3 Yhdistetty identiteetti

Yhdistetty identiteetti (engl. federated identity) perustuu identiteettien yhdistämi-seen sovitun liittouman kesken, kuten kahden tai useamman yrityksen tai palve-luntarjoajan välillä [28, s. 4]. Yhdistetystä identiteetistä käytetään kirjallisuudessamyös nimeä yhteinen käyttäjäntunnistus [33]. Vaikka identiteettirekisterien tiedotvoidaan säilyttää uniikkeina omissa ympäristöissä, voidaan liittouman kaikkien os-apuolten identiteettejä käyttää tunnistautumiseen [28, s. 4] [29]. Yhdistetty identi-teetti mahdollistaa liittouman osapuolten tarjota pääsyä suurelle määrälle käyttäjiäilman, että heidän tarvitsee yksin hallita ja ylläpitää koko identiteettiavaruutta janiiden ominaisuuksia [28, s. 4]. Ehtona yhdistetyn identiteetin käyttämiselle on yri-tysten välinen luottamus [10, s. 47] [29].

Yhdistetty identiteetti mahdollistaa myös kertakirjautumismenetelmän käytön(SSO) kaikkien osapuolten palveluiden välillä [10, s. 47]. SSO menetelmässä käyt-täjä kirjautuu vain yhteen palveluun, jonka jälkeen erillistä kirjautumista ei enäätarvita muiden osapuolten palveluiden käyttöön [28, s. 4] [11, s. 2]. Autentikointitie-to välitetään muille osapuolille identiteetin kotirekisteristä osapuolten hyväksymääturvallista ja luottamuksellista kanavaa pitkin [10, s. 47]. Toimintatapa mahdollis-taa läpinäkyvyyden osapuolten palveluiden ja käyttäjien välillä [10, s. 47]. Loppu-käyttäjän ei tarvitse olla tietoinen taustalla olevista prosesseista eikä hänen tarvitserekisteröityä jokaisen osapuolen kanssa [10, s. 47].

Kuvassa 6 on ylätason malli yhdistetystä identiteetistä. Erimuotoiset kehyksetyritysten ympärillä kuvaavat yritysten ylläpitämiä omia identiteetinhallintamalleja,jotka voivat olla riippumia muiden ylläpitämistä hallintamalleista.

18

Kuva 6: Yhdistetty identiteetti [10, s. 50]

Ero yhdistetyn identiteetin ja jaetun paikallisen identiteetin välillä on, että yh-distetyssä identiteetissä osapuolet ylläpitävät omia käyttäjärekistereitä ja tunnis-tautumistapoja, kun taas jaetussa paikallisessa identiteetissä on yksi käyttäjärekis-teri ja tunnistautumistapa, jota osapuolet käyttävät. Ongelmana yhdistetyn iden-titeetin mallissa on yhteisten käytäntöjen ja tietoturvapolitiikan hyväksyminen jaluottamussuhteiden rakentaminen. Esimerkiksi autentikointitietojen valvominen jakontrollointi suuressa liittoumassa voi osoittautua haasteelliseksi, koska osapuoltentietoturvavaatimukset saattavat erota toisistaan. [11, s. 2]

4.4 Globaali verkkoidentiteetti

Globaali verkkoidentiteetti (engl. global web identity) kuvaa identiteettiä, joka onolemassa ja tunnistettavissa koko verkossa, esimerkiksi Internetissä, ja joka edus-taa tiettyä kokonaisuutta samaan tapaan, kuin Uniform Resource Identi�er (URI)edustaa ja on tunniste tietylle internet-resurssille [12]. Globaalin verkkoidentiteetinidea on, että identiteetti voidaan yksikäsitteisesti tunnistaa ja ottaa käyttöön niinpaikallisesti kuin verkon muissa solmuissa [10, s. 51].

Muun muassa riittävän tieturvan ylläpitämisen, tarvittavien luottamussuhteidenrakentamisen ja puuttuvien standardien vuoksi ei globaalia verkkoidentiteettiä olelaajasti otettu käyttöön [11] [10]. Lupaavin globaalin verkkoidentiteetin toteutustapaperustuu XDI.ORG organisaation kehittämiin avoimiin standardeihin XRI (Exten-sible Resource Identi�er) ja XDI (XRI Data Iterchange), jotka perustuvat XML:iin(Extensible Markup Language) [13]. Näillä on tarkoitus mahdollistaa organisaatioille

19

digitaalisen Internet identiteetin luominen [10, s. 54].

20

5 Pääsynhallinta

Pääsynhallinnan tarkoituksena on tarjota käyttäjille oikeus päästä ja käyttää tietoaja IT-palveluita, joihin heillä on vahvistettu valtuus, kuitenkin eväten vahvistamat-tomien ja luvattomien käyttäjien pääsy palveluihin ja niiden käyttö [1, s. 68]. Pää-synhallinta auttaa suojaamaan tiedon luottamuksellisuuden, eheyden ja saatavuu-den [1, s. 68] sekä pyrkii osaltaan estämään haitallisen toiminnan, joka voisi johtaayrityksen tietoturvan vaarantumiseen [16, s. 40]. Tässä diplomityössä pääsynhallin-nalla tarkoitetaan käyttäjien pääsy- ja käyttöoikeuksien hallintaa tietojärjestelmiinja -ympäristöihin.

Tietoturvan- ja identiteetinhallinta ovat keskeisessä asemassa toimivan pääsyn-hallinnan toteuttamisen kannalta sillä pääsynhallintamenetelmät luottavat olemassaoleviin tietoturva- ja identiteetinhallintamenetelmiin ja pyrkivät toteuttamaan so-vittua tietoturvapolitiikkaa [16, s. 40] [10, s. 20]. Lisäksi tietoturva- ja identiteetin-hallinta osaltaan auttavat määrittelemään, onko tunnistetulla käyttäjällä oikeuttakäyttää kohderesurssia. Resurssi voi olla mikä tahansa kohde, palvelu, tietojärjes-telmä, palvelin tai tiedosto [10, s. 20]. Tässä diplomityössä käytetään termiä koh-dejärjestelmä, sillä se kuvaa parhaiten kaikkia tietojärjestelmien sisältämiä kohteita.

5.1 Reference monitor -malli

Nykyiset pääsynhallintamenetelmät perustuvat Butler Lampsonin 1970-luvulla esit-telemään reference monitor malliin [20]. Reference monitor on osa luotettua tieto-jenkäsittelypohjaa (TCB), ja se välittää pääsyn kohdejärjestelmiin sovitun turvapoli-tiikan mukaisesti [10, s. 21]. Politiikka voi olla toteutettu tulkitsemalla kohdejärjestelmä-ja käyttäjärekistereitä sääntöjen ja tuntomerkkien perusteella [10, s. 21]. Politiikkaaylläpidetään valtuutustietokannassa (authorization database), josta reference moni-tor tiedustelee, onko yritetty pääsyoperaatio sallittu [16, s. 40]. Pääsyoperaatioihinvoi olla liitettynä myös valvonta, joka pitää kirjaa olennaisista toiminnoista [16,s. 40]. Pääsynhallintaan liittyvät päätoiminnot on kuvattu kuvaan 7. Toimintojeneriytys todellisessa toteutuksessa ei ole aina selkeä, mutta niiden eriyttäminen edesloogisella tasolla auttaa hahmottamaan kokonaiskuvaa ja parantaa niiden hallitta-vuutta [16, s. 40].

21

Kuva 7: Yhdistetty identiteetti [16, s. 41]

Autentikoinnin ja pääsyn kontrolloinnin toiminnallisuuden eron ymmärtäminenon tärkeää vastuualueiden rajaamiseksi. Käyttäjän identiteetin tunnistaminen javarmistaminen kuuluu autentikointipalveluiden vastuulle, ja ne ovat osa identitee-tinhallintaa. Pääsyn kontrollointi olettaa, että käyttäjä on luotettavasti tunnistettuautentikointipalveluissa ja kyseessä oleva pääsyoikeus vahvistettu reference moni-torin toimesta. Nämä toiminnot pelkästään eivät ole kattava ratkaisu järjestelmienturvaamiseen. Tietoturvanhallinta usein vaatii, että pääsynhallintaan on liitettynämyös valvonta tai kirjanpito, jonka avulla voidaan analysoida jälkikäteen järjestel-miin kohdistuvia pääsypyyntöjä ja aktiviteetteja. [16, s. 40]

Sopivan pääsynhallintamenetelmän valinta voi olla hankalaa ja yleisesti ei oleolemassa menetelmää, joka olisi parempi kuin muut; on olemassa menetelmiä, jot-ka tarjoavat korkeamman tietosuojatason kuin toiset. Toisaalta, kaikkia järjestelmiäeivät koske samat tietoturva- ja käytettävyysvaatimukset, jolloin tiukka pääsynhal-lintamenetelmä kriittiseen järjestelmään ei välttämättä sovellu ympäristöön, jossavaaditaan joustavuutta ja käytettävyyttä. [16, s. 41]

5.2 Harkinnanvarainen pääsynhallinta (DAC)

Harkinnanvaraisessa pääsynhallinnassa (engl. discretionary access control, DAC)pääsy kohdejärjestelmään toteutetaan perustuen käyttäjän identiteettiin ja siihen

22

liitettyihin valtuuksiin tai sääntöihin, jotka määrittelevät yksittäisen käyttäjän taikäyttäjäryhmän oikeudet kohdejärjestelmään [16, s. 44]. DAC mallissa jokaiselle koh-dejärjestelmälle on määritelty yksi tai useampi omistaja, jotka voivat täysin omanharkintansa mukaan määritellä muiden käyttäjien pääsy- ja käyttöoikeuksia koh-dejärjestelmään [10, s. 25]. Lisäksi jokaisella käyttäjällä on oikeus hyväksyä pääsyheidän hallinnoimiinsa sovelluksiin kohdejärjestelmän sisällä ilman omistajan val-tuutusta [16, s. 44]. DAC:n politiikka esiintyy muodossa tai toisessa lähes kaikissapääsynhallintamenetelmissä, sillä resurssi-omistajuus malli pääsynhallinnassa on hy-vin yleinen ja vastaa todellista maailmaa [10, s. 25].

DAC -menetelmän hyötyjä ovat yksinkertaisuus, joustavuus ja käyttöönotonhelppous. Haittapuolena DAC ei tarjoa mitään oikeaa varmuutta tiedon kulusta,vaan pääsy- ja käyttöoikeuksien leviäminen on teoriassa rajoittamatonta ja vaikeas-ti ennustettavaa [10, s. 25]. Lisäksi pääsyrajoitukset on kohtuullisen helppo kiertää,sillä käyttäjät voivat sallia muille käyttäjille harkintavaltansa alaisia oikeuksia mui-den tästä tietämättä [16, s. 44].

Menetelmää sanotaan suljetuksi tai avoimeksi riippuen reference monitorin ole-tuspäätöksestä pääsylle. Suljetussa menetelmässä pääsy annetaan vain jos pääsyl-le löytyy positiivinen valtuutus kohdejärjestelmään. Avoimessa menetelmässä puo-lestaan pääsy annetaan aina, ellei erillistä negatiivista valtuutusta pääsylle löydy.Positiivisia ja negatiivisia valtuutuksia voidaan käyttää samanaikaisesti, jolloin onmahdollista määritellä tarkemmin valtuutetut ja luvattomat pääsyt, mutta niidensamanaikainen ylläpito voi muuttua monimutkaiseksi. [16, s. 44]

5.3 Pakollinen pääsynhallinta (MAC)

Pakollisessa pääsynhallinnassa (engl. mandatory access control, MAC) pääsy kohde-järjestelmiin perustuu kohdejärjestelmien ja käyttäjien luokittelemiseen tietoturva-tasoihin. Kohteeseen liitetty tietoturvataso kuvastaa kohteen sisältämän tiedon ar-kaluonteisuutta ja riskiä, minkä tiedon luvaton paljastuminen voisi aiheuttaa. Käyt-täjään liitetty tietoturvataso, toisin sanoen pääsyoikeus, kuvastaa puolestaan käyt-täjän luotettavuutta. [16, s. 44]

MAC -menetelmä kehittyi sotilashierarkian pohjalta ja soveltuukin erityisesti so-tilaallisiin ja siviilihallinnon tarpeisiin [10, s. 25]. MAC turvatasojen hierarkia voi-daan kuvata koostuvan esimerkiksi neljästä tasosta: Top Secret (TS), Secret (S),Con�dential (C) ja Unclassi�ed (U) [16, s. 44].

Päinvastoin kuin DAC:ssa, MAC mallissa ei käytetä resurssi-omistajuus mallia,vaan oikeudet määritellään hallinnollisin menettelyin etukäteen ja ne säilyvät muut-tumattomina sen jälkeen. Pääsy- ja käyttöoikeuksien leviäminen ei ole mahdollistakäyttäjien tai järjestelmien toimesta, vaan luotettu taho hallinnoi oikeuksia. MACmahdollistaa ennustettavan ja yksisuuntaisen tiedonkulun. [10, s. 25]

23

5.3.1 Bell-LaPadula -malli (BLP)

David Elliott Bell ja Leonard J. LaPadula kehittivät formaalin mallin kuvaamaanMAC menetelmän useita tietoturvatasoja [21]. Bell-LaPadula -malli (BLP) määrit-telee kaksi tiedonkulkuun vaikuttavaa sääntöä [10, s. 137]:

1. Simple security rule, joka tunnetaan myös lue alas (engl. read-down) -ominaisuutena.Lue alas -ominaisuus määrittelee, että tietoa voidaan lukea vain alemman ta-son ja oman tason kerroksista. Käyttäjä s voi lukea kohdetta o, vain jos S >=O, missä S on käyttäjän s tietoturvataso ja O kohteen o tietoturvataso. [10,s. 137]

2. *-property (tähti-ominaisuus), joka tunnetaan myös kirjoita ylös (engl. write-up) -ominaisuutena. Kirjoita ylös -ominaisuus määrittelee, että käyttäjä s voikirjoittaa kohteeseen o, vain jos O >= S. Menetelmä estää käyttäjän tiedonkulkeutumasta muille tahoille kuin niille, jotka ovat korkeammalla tai samallatasolla kuin käyttäjä. [10, s. 137]

Lue alas ja kirjoita ylös -ominaisuuksien mukainen tiedonkulku on kuvattu ku-vaan 8.

Kuva 8: Bell-LaPadula -mallin mukainen tiedonkulku [16, s. 45]

BLP -mallin kirjoita ylös -ominaisuus yksinään ei ole riittävä suoja estämääntietojen vääristymistä ylemmillä tasoilla, millä käyttäjä on [10, s. 137]. Ominaisuusesimerkiksi mahdollistaa käyttäjän tasolla S ylikirjoittaa kohteita tasolla TS [16, s.45]. Eheyden säilyttämiseksi ylemmillä tasoilla voidaan ongelma ratkaista muokkaa-malla kirjoita ylös -ominaisuutta siten, että käyttäjä s voi kirjoittaa kohteeseen o,vain jos S=O [10, s. 137].

24

5.3.2 Biba -malli

Siinä missä BLP -malli pyrkii estämään luottamuksellisen tiedon kulkeutumisen epä-luotetulle tasolle, Biba -malli pyrkii varmistamaan tiedon eheyden [10, s. 139]. Biba-malli seuraa samaa ideaa kuin BLP, eli tasojen tiedonkulkusuunta on määriteltysäännöillä, mutta lähestyy ratkaisua eri suunnalta [10, s. 139]. Myös Biba -mallimäärittelee tiedonkulun kahdella säännöllä [10, s. 139]:

1. Simple-integrity property, joka tunnetaan myös lue ylös (engl. read-up) -ominaisuutena. Lue ylös -ominaisuus määrittelee, että käyttäjä s voi lukeakohdetta o, vain jos O >= S. [10, s. 139] [16, s. 45]

2. Integrity *-property, joka tunnetaan myös kirjoita alas (engl. read-down) -ominaisuutena. Kirjoita alas -ominaisuus määrittelee, että käyttäjä s voikirjoittaa kohteeseen o, vain jos S >= O. [10, s. 139] [16, s. 45]

Lue ylös ja kirjoita alas -ominaisuuksien mukainen tiedonkulku on kuvattu ku-vaan 9. Biba -mallissa tasot kuvaavat eheyden tärkeyttä, eli kuinka paljon kohteensisältämän tiedon sisältöön voidaan luottaa. Kuvan 9 tasot ovat Crucial (C), Impor-tant (I) ja Unknown (U). [16, s. 45]

Kuva 9: Biba -mallin mukainen tiedonkulku [16, s. 46]

Huomionarvoista on, että Biba -mallissa tiedonkulun suunta on vastainen BLP-malliin verrattaessa. Perinteisissä MAC -menetelmissä tiedonkulku on yksisuuntais-ta. [16, s. 45]

5.4 Roolipohjainen pääsynhallinta (RBAC)

Organisaatioissa pääsynhallintapäätökset perustuvat usein henkilöiden varsinaiseentyönkuvaan � rooliin � joka on heille määritelty. Tämä kattaa tehtävien, vastuualuei-den ja valtuuksien erittelyn. Roolipohjaisen pääsynhallinta (engl. role-based access

25

control, RBAC) -menetelmän pääsynhallintapäätökset perustuvat juuri henkilöönkohdistuviin toimintoihin ja työnkuviin, joita hänen sallitaan suorittavan organi-saatiossa. RBAC kehitettiin vaihtoehdoksi DAC ja MAC -menetelmille tarjoamaansopivampi ja keskitetty ratkaisu teollisuuden ja siviilihallinnon tietoturvatarpeisiin.RBAC -menetelmän esittelivät ensimmäisen kerran Ferraiolo ja Kuhn vuonna 1992.[22]

Toisin kuin DAC ja MAC -menetelmissä, joissa oikeudet on määritelty suoraankäyttäjille, RBAC -menetelmässä oikeudet on määritelty roolille [10, s. 26] ja roolivuorostaan voidaan määritellä yhdelle tai usealle käyttäjälle [22]. RBAC -menetelmämahdollistaa pääsynhallinnan suunnittelun abstraktimmalla tasolla, tehden hallin-tapolitiikasta neutraalimman kuin DAC ja MAC -menetelmissä [10, s. 26].

Rooli voidaan ajatella nippuna sallittuja valtuuksia, joita voidaan suorittaa or-ganisaatiossa, tai rooli voidaan määritellä muodostuvan muista rooleista [22]. Tämähelpottaa roolien kuvaamista organisaation hierarkkisen rakenteen mukaan [10, s.191]. Rooleihin määritellyt valtuudet voidaan edelleen määritellä varsinaisiksi jär-jestelmäkohtaisiksi käyttöoikeuksiksi, eli todellisiksi asetuksiksi joilla oikeus toteu-tetaan [10, s. 191]. Kuva 10 havainnollistaa valtuuksien, roolien, käyttäjien ja käyt-töoikeuksien keskinäiset yhteydet.

Kuva 10: Valtuuksien, roolien, käyttäjien ja käyttöoikeuksien keskinäiset yhteydet[10, s. 192]

Kuva 11 havainnollistaa roolien hierarkkista muodostustapaa.

26

Kuva 11: Esimerkki yksinkertaisesta roolihierarkiasta (yhden roolin perintä) [10, s.199]

5.4.1 Roolien määrittely ja hallinta

Roolien hallinta ja ylläpito voidaan määritellä kuuluvan osaksi pääsynhallintapro-sessia ja pääsynhallintaprosessin tulee osaltaan huolehtia roolien sopivuudesta yri-tyksen toimintaan suorittamalla säännöllisiä tarkastuksia rooleihin. Vanhentuneetja ei-toivotut roolit tulee poistaa. [1, s. 69]

Valtuudet rooleille määritellään joko järjestelmävalvojan toimesta [22], palve-lun omistajan toimesta tai osana jatkuvaa pääsynhallintaprosessia [1, s. 69]. Roolinmääritteleminen ei kuitenkaan ole kertaluonteinen tapahtuma, vaan niihin tulee teh-dä tarkennuksia ja korjauksia säännöllisin väliajoin [25, s. 3]. Roolien määrittelystäkäytetään kirjallisuudessa myös termiä role engineering [26].

Mitä enemmän rooleja on määritelty, sitä suuremmalla todennäköisyydellä roo-lien ristiriitaisuuksia ilmenee. Esimerkiksi jokin rooli sallii käyttäjän suorittaa tie-tyn toiminnon, kun taas toinen rooli kieltää tämän toiminnon suorittamisen. [1, s.69] Lisäksi roolien suunnittelussa joudutaan aina miettimään, onko toimenpiteitämääritelty rooliin liian laajasti tai liian suppeasti [1, s. 69] Roolien ristiriitaisuuk-sia voidaan yrittää estää ja määrittelyn laajuutta kontrolloida roolien huolellisellasuunnittelulla [1, s. 69], luvussa 3.1.1 mainitulla tehtävien eriyttämisellä sekä luvus-sa 3.1.2 mainitulla pienimmän oikeuden periaatteella.

Roolien määrittelylle on olemassa kaksi keskeistä lähestymistapaa: Top-down jabottom-up. Top-down menetelmässä roolit määritellään pilkkomalla liiketoiminta-prosessit pienemmiksi toiminnallisiksi yksiköiksi, joille kartoitetaan tarvittavat val-tuudet. Toisin sanoen menetelmässä kuvataan yksittäiset työtehtävät rooleiksi mää-rittelemällä niille niiden tarvitsemat valtuudet. Bottom-up menetelmässä roolit kar-toitetaan olemassa olevien oikeuksien perusteella. Menetelmän etuna on, että roolienmäärittely voidaan osittain automatisoida. [27, s. 1]

27

6 Tapaustutkimus: Pääsynhallintamenetelmät

IT-ulkoistuspalveluntarjoajayrityksessä

Tässä tapaustutkimuksessa selvitetään miten ja minkälaisilla menetelmillä pääsyn-hallinta on toteutettu Atos IT Solutions and Services Oy -yrityksessä. Tutkimuksentarkoituksena on kartoittaa yrityksen pääsynhallinnan nykytila ja osoittaa siitä löy-detyt ongelmakohdat sekä arvioida niiden vaikutukset yrityksen toimintaan.

Yrityksen pääsynhallinnan toteutuksen kartoitus aloitettiin selvittämällä, mitenpääsynhallinta on palvelutoimintona yrityksessä määritelty ja minkälaisilla työka-luilla pääsynhallintaa toteutetaan. Käytetyt työkalut selvitettiin kysymällä esimie-hiltä ja palveluiden omistajilta, miten uusille työntekijöille haetaan oikeuksia tieto-kohteisiin ja palveluihin, joita tarvitaan työn suorittamiseen. Työkalujen toiminta-tapaa selvitettiin lukemalla olemassa olevia dokumentaatioita ja ohjeita, tekemällätestitapauksia oikeuksienhausta ja haastattelemalla työntekijöitä. Toimintatavastaselvitettiin, mitä kohdejärjestelmiä niillä voidaan hakea ja minkälaista identiteetin-ja pääsynhallintamallia niissä noudatetaan.

Tapaustutkimuksessa selvitettiin myös, paljonko käyttöoikeuspyyntöjä työkalu-jen kautta kulkee, kauanko niiden läpivienti kestää ja kuinka paljon manuaalistatyötä pyyntöihin sisältyy. Osa tiedoista saatiin työkaluista itsestään ja osa kerät-tiin haastatteluin ja tekemällä testikäyttöoikeuspyyntöjä. Havaintojen perusteellatyökaluista koostettiin yhteenveto merkittävimmiksi koetuista ongelmakohdista. Li-säksi arvioitiin työkalujen soveltuvuutta yrityksen nykyiseen liiketoimintatapaan ja-tarpeisiin.

6.1 Pääsynhallinta palvelutoimintona ja käytetyt työkalut

Pääsynhallintaa ei ole yrityksessä määritelty itsenäiseksi palvelutoiminnoksi. Sen si-jaan pääsynhallintaa toteutetaan kahden eri työkalun avulla: Check In Request (CIR)ja Access Request Approval Process (ARAP). Koska pääsynhallinta ei ole määriteltyitsenäiseksi palvelutoiminnoksi, pääsynhallintaan liittyviä toimintoja ei ohjata taivalvota kenenkään toimesta eikä sille ole määritelty tarkasti vaatimuksia tietotur-van tai palvelun ylläpitämisen ja kehittämisen osalta.

Työkalut ARAP ja CIR eroavat toisistaan niin toiminnaltaan kuin sisällöltään.Työkaluista on tarjolla niukasti dokumentaatiota, mikä johtuu suurelta osin siitä,että molemmat työkalut ovat pitkälti yrityksen omiin tarpeisiin räätälöityjä.

28

6.1.1 Check In Request (CIR)

Check In Request (CIR) on Lotus Notes Domino -pohjainen käyttöoikeuksien hake-miseen tarkoitettu sovellus. Sovellus ei ole aktiivisesti kytketty kohdejärjestelmiin,eli se ei lue kohdejärjestelmistä niiden sisältämiä käyttöoikeuksia eikä se provisioioikeuksia suoraan kohdejärjestelmiin. CIR ylläpitää tietoa käyttäjille sitä kauttahaetuista ja hyväksytyistä valtuuksista, ja se on tarkoitettu vain yrityksen sisäiseenkäyttöön.

CIR:lla haetaan oikeuksia pääasiallisesti yrityksen sisäisiin kohdejärjestelmiin,kuten tietokantoihin ja sovelluksiin, mutta sinne on mahdollista määrittää myösmuita kohteita. Haettavat kohteet ovat luokiteltu kategorioihin ja näistä edelleenvarsinaisiin käyttöoikeuskohteisiin. Riippuen kategoriasta, kohteet on kuvattu jokonimitasolla tai rooleina ja varsinaisen käyttöoikeuden laajuus ja tyyppi valitaan jokovalintanapeista tai kirjoitetaan lisätiedot -kenttään. CIR:n käyttöliittymä on mukau-tettavissa usean erityyppisen käyttöoikeuskohteen mukaiseksi.

Käyttöoikeuskohteet on määritelty erilliseen sovellustietokantaan jota CIR lukee.Jokaiselle haettavalle kohteelle on määritelty pääkäyttäjä, joka toimii neljän silmänperiaatteen mukaisesti yhtenä hyväksyjänä kohteeseen liittyvissä pyynnöissä. Pää-käyttäjän vastuu on myös määritellä ne todelliset käyttöoikeudet, jotka kohteeseentoteutetaan.

6.1.2 Access Request Approval Process (ARAP)

Access Request Approval Process (ARAP) on web-portaalin kautta toimiva käyttö-oikeuksien hakemiseen tarkoitettu sovellus. Samoin kuin CIR, myöskään ARAP eiole aktiivisesti kytketty kohdejärjestelmiin, eli se ei lue kohdejärjestelmistä niidensisältämiä käyttöoikeuksia, eikä se provisioi oikeuksia suoraan kohdejärjestelmiin.ARAP ylläpitää tietoa käyttäjille sitä kautta haetuista ja hyväksytyistä valtuuksis-ta.

ARAP:n kautta voidaan hakea oikeuksia yrityksen työntekijöille yrityksen omiinkohdejärjestelmiin ja yrityksen ylläpitämiin asiakasjärjestelmiin. Vaikka palvelu onmahdollista tarjota myös yrityksen ulkopuolisille tahoille, on päätetty, että vainyrityksen sisäiset työntekijät voivat luoda ARAP:n kautta pyyntöjä. ARAP myösmahdollistaa ulkopuolisten hyväksyjien käytön, jolloin hyväksyntäketjussa voidaantarvittaessa käyttää asiakkaan yhteyshenkilöä.

ARAP:n kautta haettavista kohdejärjestelmistä ei löytynyt olemassa olevaa do-kumentaatiota. Työkalun käyttämää kohdejärjestelmätietokantaa tutkimalla onnis-tuttiin työstämään kattava listaus ARAP:n kautta haettavista kohdejärjestelmistäja listauksen ylläpito siirrettiin työkalun ylläpitäjän vastuulle. Lisäksi tutkimuksenohella tehtiin ohjeistus organisaation työntekijöille, jossa kerrottiin, mitä oikeuksia

29

ARAP:n kautta on tarkoitus hakea ja miten ne eroavat CIR:stä.

Pääpiirteittäin ARAP:n kautta on mahdollista hakea seuraavanlaisia oikeuksia:

• Kaikki domain admin oikeudet yrityksen kohdejärjestelmiin

• Kaikki domain admin oikeudet ylläpidettyihin asiakasjärjestelmiin

• Kulkuluvat palvelinhuoneisiin

Haettavia käyttöoikeuskohteita ylläpidetään erillisessä Hardware Info tietokan-nassa ja tietojen ylläpidosta vastaa yrityksen Con�guration Management yksikkö.Hardware Info on manuaalisesti ylläpidetty tietokanta ja muutokset sinne on mää-ritelty tehtäväksi osana Change ja Con�guration Management prosesseja.

Kohteet on ryhmitelty asiakkaittain ja tämän jälkeen palvelu-/tuotantojärjestelmienperusteella. Tietokanta mahdollistaa teknisen- ja yrityshyväksyjän asettamisen jo-kaiselle kohteelle yksitellen. Tietokanta ei tue kohteiden etsintää nimillä, vaan ARAPpyynnön tekijän tulee tietää tai osata etsiä oikea kohde asiakkuuden palvelu- tai tuo-tantojärjestelmien alta.

6.2 Identiteetinhallintamenetelmät

CIR ei ylläpidä itsessään käyttäjien identiteettejä eikä täten toteuta identiteetin-hallintaa sellaisenaan. Käyttäjätiedot luetaan suoraan HR:n ylläpitämästä Citizenhenkilötietokannasta. CIR:n kautta ei voida muokata identiteettejä. CIR tallentaaomaan tietokantaansa tiedon sitä kautta käyttäjille haetuista ja hyväksytyistä val-tuuksista.

Citizen toimii luvussa 4.1 esitellyn jaetun paikallisen identiteetin mallin mukai-sesti, eli useampi järjestelmä voi lukea sen ylläpitämän käyttäjärekisterin tietoja.Käyttäjälle, jonka henkilötietoja ei ole Citizen tietokannassa, ei voida hakea CIR:nkautta oikeuksia. Tämä rajaa CIR käyttäjäkunnan yrityksen sisäisiin työntekijöihinja niihin kolmansiin osapuoliin tai globaalin organisaation sisäisiin partnereihin, jot-ka on kirjattu Citizen tietokantaan.

ARAP ylläpitää omaa paikallisen identiteetin mallin mukaista käyttäjärekisteriä,eikä se ole kytköksissä yrityksen HR järjestelmään. ARAP:n ylläpitämä käyttäjä-rekisteri on jaettu saman portaalin kautta toimivan, muutospyynnöille tarkoitetunCMweb (Change Management web) konsolin kanssa.

ARAP:n identiteetin hallinnan yhdeksi ongelmakohdaksi havaittiin, että käyttä-järekisteri ei osaa poistaa vanhentuneita käyttäjätilejä automaattisesti, vaan poistottulee tehdä järjestelmän ylläpitäjän toimesta manuaalisesti. Lisäksi tiliin liitetyt oi-keudet tulee pyytää poistettaviksi erikseen.

30

Pääsynhallintatyökaluihin liittyvien identiteettien lisäksi yrityksessä on käytös-sä verkkoidentiteetit työntekijälle, joita hallinnoidaan Microsoft Active Directorynavulla. Active Directory sisältää tiedon verkon käyttäjistä ja resursseista, ja mahdol-listaa resurssien jakamisen käyttäjille luvussa 4.2 esitellyn verkkoidentiteetin mallinmukaisesti. Sekä ARAP:lla että CIR:llä voidaan hakea verkkoidentiteeteille pääsy-oikeuksia valittuihin verkon resursseihin.

6.3 Pääsynhallintamenetelmät

CIR:n toimintatapa noudattaa perusperiaatteeltaan luvussa 5.2 esitellyn suljetunharkinnanvaraisen pääsynhallintamallin (DAC) toimintatapaa. Pääsy kohdejärjes-telmiin toteutetaan perustuen käyttäjän identiteettiin ja siihen liitettyihin valtuuk-siin, lisäksi kaikille haettaville kohdejärjestelmille on määritelty pääkäyttäjä. CIRtoimii pitkälti luvussa 5.2 esitellyn reference monitorin tavoin, jota vasten voidaantarkastaa, saako henkilöllä olla tietyt oikeudet järjestelmiin.

Erona varsinaiseen määritelmään DAC:sta CIR:n toimintatavassa pääkäyttäjäei itse luo varsinaisia oikeuksia kohdejärjestelmään, vaan toimii ainoastaan yhte-nä hyväksyjänä pyynnöille. Oikeuksienhaussa noudatetaan luvussa 3.1.1 esitellyntehtävien eriyttämisen (SoD) mukaista tietoturvapolitiikkaa toimimalla yrityksentietoturvahallinnan määrittelemän neljän silmän periaatteen mukaisesti. Jokaiseenpyyntöön tarvitaan kaksi hyväksyjää: esimies ja pääkäyttäjä. Tämä estää tilanteen,jossa käyttäjä voisi hakea ja hyväksyä oikeuden itselleen, jossa toimii pääkäyttäjä-nä. Lisäksi jos esimies ja pääkäyttäjä ovat yksi ja sama henkilö, asetetaan esimiehenesimies toiseksi hyväksyjäksi automaattisesti.

Samoin kuin CIR myös ARAP:n toimintatapa noudattaa perusperiaatteeltaanluvussa 5.2 esitellyn suljetun harkinnanvaraisen pääsynhallinnan mallia (DAC). Pää-sy kohdejärjestelmiin toteutetaan perustuen käyttäjän identiteettiin ja siihen liitet-tyihin valtuuksiin. ARAP ei mahdollista pääkäyttäjien määrittämistä kohdejärjes-telmille, mutta mahdollistaa teknisten- ja yrityshyväksyjien asettamisen kohdejär-jestelmille. Myös ARAP toimii luvussa 5.2 esitellyn reference monitorin tavoin. Sitävasten tarkistetaan, saako henkilöllä olla tietyt oikeudet järjestelmiin.

ARAP:n pääsynhallinnassa pyritään myös noudattamaan tehtävien eriyttämis-tä (SoD) neljän silmän periaatteen avulla siten, että jokaiseen pyyntöön vaaditaanvähintään kaksi hyväksyjää: esimies ja tekninen hyväksyjä tai mahdollinen yrityshy-väksyjä. SoD on kuitenkin mahdollista kiertää ja sitä on mahdollista manipuloida.Jokainen avattu pyyntö tarvitsee tarkistaa ja lähettää eteenpäin pääsynhallinta-koordinaattorin toimesta ennen hyväksyntää. Pääsynhallintakoordinaattori asettaapyynnölle hyväksyjät. Tämä mahdollistaa kaikkien pääsynhallintakoordinaattorioi-keuksien omaavien henkilöiden pystyvän tekemään, sekä hyväksymään, itselleen mi-tä tahansa käyttöoikeuksia.

31

6.4 Prosessi ja osapuolet

Käyttoikeuspyyntöjen käsittely ja toteutus CIR:lla kartoitettiin tekemällä viisi tes-tikäyttöoikeuspyyntöjä ja haastattelemalla kahta työkalun aikaisempaa kehittäjää.Haastattelut olivat vapaamuotoisia ja testikäyttöoikeuspyynnöt rajoittuivat yrityk-sen SharePoint ympäristön kohteisiin. Saaduista tuloksista CIR:n toimintatapa ku-vattiin prosessiksi, joka koostuu viidestä vaiheesta:

1. Pyynnön avaus ja määrittely. Käyttöoikeuspyyntö avataan CIR:iin ja sii-hen määritellään mitä oikeutta haetaan, kenelle haetaan ja miksi haetaan.Oikeuspyynnön voi avata kuka tahansa yrityksen sisäinen työntekijä.

2. Hyväksyntä. Käyttöoikeuspyyntö ohjautuu CIR:iin asetettujen tietojen mu-kaisesti hyväksyttäväksi ensin oikeuden saajan esimiehelle ja tämän jälkeenhaettavaan oikeuteen liittyvän kohdejärjestelmän pääkäyttäjälle. Hyväksyn-nän jälkeen CIR tallentaa tietokantaansa tiedon, että käyttäjällä on valtuushaettuun oikeuteen.

3. Koordinointi. CIR luo käyttöoikeuspyynnöstä sähköpostin yrityksen ServiceDeskiin, joka tulkitsee sen ja luo siitä palvelupyynnön tiketöintijärjestelmään.Palvelupyyntö ohjautuu tiketöintijärjestelmästä oikeuden toteutuksesta vas-taavalle tuotantotiimille.

4. Toteutus. Tuotantotiimi tulkitsee palvelupyynnössä pyydetyn käyttöoikeu-den tiedot ja toteuttaa ne kohdejärjestelmään. Tuotantotiimi on vastuussamyös toteutuksen tiedottamisesta pyynnön luojalle ja oikeuden saajalle.

5. Sulkeminen. Tuotantotiimi ilmoittaa oikeuden saajalle oikeuden toteutuk-sesta ja tämän jälkeen tuotantotiimi sulkee palvelupyynnön tiketöintijärjestel-mästä.

Vastaavasti ARAP:n käyttöoikeuspyyntöjen käsittelyyn ja toteutukseen tutus-tuttiin tekemällä viisi testikäyttöoikeuspyyntöjä ja haastattelemalla yhtä proses-sikoordinaattoria. Testikäyttöoikeuspyynnöt rajoittuivat yrityksen testiympäristö-jen oikeuskohteisiin. Haastattelu oli vapaamuotoinen. Lisäksi tutustuttiin työkalustaluotuun käyttöoppaaseen. Näiden perusteella työkalun toimintatavasta tehtiin pro-sessikuvaus, joka koostuu kuvan 12 mukaisesti viidestä vaiheesta. Kuva 12 tehtiin,englanniksi, sillä kohdeyrityksen työkielenä käytetään englantia.

Kuva 12: Käyttöoikeuspyyntöjen käsittelyn vaiheet ARAP:ssa

32

1. Määrittely.Käyttöoikeuspyyntö avataan ARAP:iin ja siihen määritellään mi-tä oikeutta haetaan, kenelle haetaan ja miksi haetaan. Käyttöoikeuspyynnönvoi avata kuka tahansa yrityksen sisäinen työntekijä.

2. Koordinointi. Pääsynhallintakoordinaattori tarkistaa käyttöoikeuspyynnönsisällön ja pyytää siihen tarvittaessa tarkennuksia ja korjauksia oikeuden avaa-jalta. Koordinaattori myös tarkistaa ja tarvittaessa lisää oikeat hyväksyjätpyynnölle ja tämän jälkeen lähettää pyynnön hyväksyjille hyväksyttäväksi.

3. Hyväksyntä.Käyttöoikeuspyynnöstä ohjautuu sähköpostiviesti asetetuille hy-väksyjille. Hyväksyjien tulee tarkastaa pyyntö ja joko hyväksyä tai hylätä se.Kun pyyntö on hyväksytty, pääsynhallintakoordinaattori luo pyynnön perus-teella palvelupyynnön yrityksen tiketöintijärjestelmään.

4. Toteutus. Tuotantotiimi tulkitsee palvelupyynnössä pyydetyn käyttöoikeu-den tiedot ja toteuttaa ne kohdejärjestelmään.

5. Sulkeminen. Tuotantotiimi on vastuussa sulkemisista. ARAP lähettää oikeu-den saajalle viestin oikeuden toteutumisesta sulkemisen tapahtuessa. ARAP:ntietokantaan jää tieto käyttäjälle haetusta ja toteutetusta oikeudesta.

6.5 Pyyntöjen määrät, läpivientiaika ja käytetty aika

CIR:n kautta tehdyt käyttöoikeuspyynnöt tallentuvat CIR:n ylläpitämään tietokan-taan haetuista oikeuksista. CIR:n kautta haettavat oikeudet lajiteltiin Sharepointpyyntöihin ja muihin pyyntöihin, sillä Sharepoint pyyntöjä on CIR:n kautta haetta-vista oikeuksista yli puolet. Oikeuden saaminen Sharepointtiin on usein hyvin oleel-lista työtehtävien suorittamisen mahdollistamiseksi.

ARAP:n kautta tehdyt käyttöoikeuspyynnöt tallentuvat ARAP:n ylläpitämääntietokantaan. Tietokannasta saatiin selville pyyntöjen määrät, mutta tietokanta eikuitenkaan sisällä tietoa kauanko pyynnön eri vaiheisiin on kulunut aikaa eikä tietoakauanko pyyntöihin on käytetty aikaa käyttäjien toimesta.

6.5.1 Pyyntöjen määrät

Pyyntöjen määriä tarkasteltiin neljän kuukauden jaksolta, josta otettiin keskiarvokuvaamaan kuukausittaista volyymia. CIR:n osalta tarkasteltujen käyttöoikeuspyyn-töjen määrät ja keskiarvot löytyvät taulukosta 1.

33

Taulukko 1: Käyttöoikeuspyyntöjen määrät CIR:ssä.

Neljän kuukaudenkokonaismäärä

Kuukausittainenkeskiarvovolyymi

SharePoint pyynnöt 303 76Tiketöintityökalusta hae-tut muut CIR:ssä luodutkäyttöoikeuspyynnöt

292 73

Kokonaismäärä: 595 149

ARAP:n kautta kulkevien käyttöoikeuspyyntöjen määrät saatiin siirtämällä tie-tokannan tiedot taulukkolaskentaohjelmaan. Myös ARAP pyyntöjen määriä tarkas-teltiin neljän kuukauden jaksolta, josta laskettiin kuukausittainen keskiarvovolyymi.ARAP:n osalta tarkasteltujen käyttöoikeuspyyntöjen määrät ja keskiarvo löytyvättaulukosta 2.

Taulukko 2: Käyttöoikeuspyyntöjen määrät ARAP:ssä.

Neljän kuukaudenkokonaismäärä

Kuukausittainenkeskiarvovolyymi

Määrä 436 109

6.5.2 Pyyntöjen läpivientiaika

Läpivientiaikojen tarkastelussa tilannetta hankaloitti se, että CIR:stä ei saatu tietoaulos taulukkomuotoisesti, vaan pyyntöjä täytyi tarkastella työkalusta käsin yksi ker-rallaan. Läpivientiaikoja ei myöskään voitu vahvistaa muiden kuin Sharepoint pyyn-töjen osalta, sillä tiketöintityökalun aikaleimat antavat vain toteutumisesta sulkeu-tumiseen kuluvan ajan. Haastatteluilla kerätyistä tiedoista ja käyttäjien kokemuk-sista voidaan kuitenkin olettaa, että muiden käyttöoikeuspyyntöjen läpivientiajatovat samansuuntaisia kuin Sharepoint pyyntöjen.

Pyyntöjen läpivientiajoista CIR:ssa löydettiin suurta vaihtelua; jotkin pyynnötsaattoivat toteutua päivän sisällä ja jotkin saattoivat kestää jopa kuukausia. Läpi-vientiaikojen ääripäitä edustavien pyyntöjen määrän arvioitiin olevan 20 % kaikistapyynnöistä, perustuen työkalusta tarkistettuihin pyyntöihin. Tarkastelusta jätettiinpois läpivientiaikojen räikeät ääripäät ja tarkastelu suoritettiin vain rajatulle mää-rälle pyyntöjä.

Pyyntöjen läpivientiaikaa CIR:ssa tarkasteltiin siitä hetkestä, kun pyyntö on luo-tu järjestelmään, siihen, kun se on kuitattu toteutetuksi. Vain toteutuneet pyynnöt

34

otettiin tarkasteluun. Taulukossa 3 on CIR pyyntöjen keskimääräiset ajat jaoteltu-na kolmeen osaan: 1) avaamisesta hyväksymiseen kulunut aika, 2) hyväksynnästäsulkeutumiseen kulunut aika ja 3) kokonaisläpivientiaika. Näistä ajoista kokonaislä-pivientiaika on loppukäyttäjän kokema aika.

Taulukko 3: Pyyntöjen läpivienti ajat CIR:ssä.

Avaamisesta hyväk-symiseen kulunutaika

Hyväksymisestäsulkeutumiseenkulunut aika

Kokonaisläpivientiaika

Keskiarvotunteina

129 130 260

Keskiarvo ka-lenteripäivinä

5,4 5,4 10,8

ARAP pyyntöjen läpivientiaikojen tarkasteltiin tekemällä kymmenen testikäyt-töoikeuspyyntöä ja haastattelemalla neljää oikeuden saajia ja yhtä pääsynhallinta-koordinaattoria. Testikäyttöoikeuspyyntöihin ja haastatteluihin perustuen koostet-tiin taulukon 4 mukaiset arviot pyynnön elinkaaren eri vaiheiden viemästä ajasta jakokonaisläpivientiajasta.

Taulukko 4: Pyyntöjen läpivienti ajat ARAP:ssa.

Määrittelystähyväksyntävai-heeseen kulunutaika

Hyväksynnästätoteuttamisvai-heeseen kulunutaika

Toteuttamisestasulkeutumiseenkulunut aika

Kokonais-läpivientiaika

Arviotunteina

24 120 48 192

Päivinä 1 5 2 8

6.5.3 Pyyntöihin käytetty aika

Pyyntöihin käytetty aika arvioitiin haastattelujen perusteella. Haastateltavat antoi-vat arvion pyyntöön keskimäärin käyttämästään ajasta. Haastattelut kohdistuivatsellaisiin käyttäjiin, jotka luovat pyyntöjä, ja käyttäjiin, jotka hyväksyvät pyyntöjä.Haastattelut olivat luonteeltaan avoimia, joissa haastateltavat saivat kertoa ominsanoin mitä toimintoja tekevät käyttöoikeuspyyntöihin liittyen ja kauanko aikaa nii-hin kuluu.

35

Pyynnön luomiseen käytetty aika arvioitiin siitä hetkestä, kun käyttäjä avaa työ-kalun, siihen hetkeen, kun hän on täyttänyt tarvittavat tiedot pyyntöön ja tallenta-nut sen. Samoin hyväksyntään käytetty aika arvioitiin siitä hetkestä, kun hyväksyjäavaa työkalun, siihen hetkeen, kun hyväksyjä painaa hyväksyntä painiketta. Toteut-tamiseen käytettyä aikaa arvioidaan työn myöhemmässä osiossa 6.6 Pyyntöjen to-teutus. Pyyntöihin käytetyt ajat koskevat sekä CIR:n että ARAP:n kautta luotujapyyntöjä, ellei toisin mainita.

Pyynnön luomisen osalta haastateltiin viittä työntekijää, joista kolme oli esi-miesasemassa ja kaksi tuotantotiimin asiantuntijoita. Pyynnön luomiseen arvioitiinkäytettävän keskimäärin 15 minuuttia, josta suurin osa kuluu kohdejärjestelmän etsi-miseen listasta. Hyväksynnän osalta haastateltiin viittä työntekijää, joista kolme olisekä esimiehiä että palvelunomistajia ja kaksi työkalun/palvelun omistajia. Hyväk-syntään hyväksyjät arvioivat käyttävänsä keskimäärin 5 minuuttia, josta suurin osakuluu pyynnön tarpeellisuuden arvioimiseen. Neljän silmän periaatteen mukaisestihyväksyjiä on aina kaksi, jolloin kokonaisaika hyväksyjien osalta on 10 minuuttia.ARAP:n osalta haastateltiin vielä pääsynhallintakoordinaattoria, joka arvioi käyt-tävänsä yhden oikeuspyynnön käsittelyyn sen elinkaaren aikana keskimäärin 15 mi-nuuttia.

CIR:n osalta osapuolten yhteenlaskettu yhteen pyyntöön käyttämä työaika on25 minuuttia. ARAP:n osalta osapuolen yhteenlaskettu yhteen pyyntöön käyttämätyöaika on 40 minuuttia.

6.6 Pyyntöjen toteutus

Sekä CIR:n että ARAP:n kautta pyydettyjen käyttöoikeuksien varsinainen toteutustehdään asiantuntijatiimeissä. Tieto tiimeille tulee tiketöintityökalun kautta palve-lupyyntöinä. Taulukoista 3 ja 4 löytyvät arviot siitä, kauanko hyväksymisestä sulke-miseen menee aikaa tai kauanko toteuttamiseen menee aikaa. Nämä ajat kuvaavataikaa, jonka pyyntö on tiketöintityökalussa.

Varsinainen oikeuden toteutukseen käytetty aika selvitettiin haastattelemalla tii-mien asiantuntijoita. Kävi ilmi, että oikeuksien toteutuksen vaatima varsinainen työ-määrä on varsin pieni. Haastateltavat arvioivat kokonaisajaksi yhtä pyyntöä kohdenkuluvan keskimäärin 15 minuuttia.

Jos verrataan CIR:n läpivientiajassa mainittua hyväksymisestä sulkeutumiseenkulunutta aikaa (130 h) ja ARAP:n läpivientiajassa mainittua toteuttamisessa kulu-nutta aikaa (48 h) varsinaiseen työn toteuttamiseen käytettyyn aikaan (15 min), huo-mataan, että ero on erittäin suuri. Aikaerot on kuitenkin helppo perustella. CIR:ntapauksessa aikaa kuluu siihen, että hyväksynnän jälkeen pyyntö lähtee työkalus-ta sähköpostina Service Desk :iin. Service Desk avaa sähköpostin, tulkitsee sen jaluo sen perusteella palvelupyynnön tiketöintijärjestelmään. Palvelupyyntö ohjautuu

36

asiantuntijatiimin jonoon odottamaan ja vasta jonosta se valitaan toteutettavaksi.Vastaavasti ARAP:n tapauksessa hyväksynnän jälkeen pääsynhallintakoordinaatto-ri luo palvelupyynnön tiketöintijärjestelmään, jossa se ohjautuu asiantuntijatiiminjonoon odottamaan ja vasta jonosta se valitaan toteutettavaksi.

Tuloksista voidaan todeta, että pyyntöjen toteuttamisajasta suurin osa meneeodottamiseen Service Deskin sähköpostissa, pyynnön tulkitsemiseen ja muuttami-seen palvelupyynnöksi tiketöintijärjestelmään sekä jonottamiseen tiketöintijärjestel-mässä tuotantotiimin jonossa. Itse oikeuden toteutus vie vain pienen osan koko to-teuttamisajasta.

6.7 Havaitut ongelmakohdat työkaluissa

Työkalujen toiminnallisuutta, läpivientiaikoja ja käyttäjähaastattelujen tuloksia tut-kimalla tehtiin yhteenveto merkittäviksi koetuista ongelmakohdista. Ongelmakoh-tien perusteella tutkimuksessa tehtiin lyhyt arvio ongelmakohdan toiminnallisestaseurauksesta. Lisäksi arvioitiin mahdollinen liiketoiminnallinen vaikutus, jonka tar-koitus on helpottaa ongelmakohtien priorisointia yrityksessä myöhemmin. Lisäksihuomattiin, että ongelmat ovat luonteeltaan joko yrityksen resursseja tuhlaavia, tie-toturvaa uhkaavia tai molempia. Taulukko 5 sisältää CIR:stä kerätyt ongelmakohdasja taulukko 6 ARAP:sta kerätyt ongelmakohdat.

37

Taulukko 5: Havaitut ongelmakohdat CIR:ssa

No. Ongelmakohta Toiminnallinen seuraus Liiketoiminnallinen vai-kutus

Luonne(R=resurssejatuhlaava,T=tietoturvaauhkaava)

1 Ei mahdolli-suutta luodasääntöihin taiautomaatioonperustuvaakäyttöoikeuk-sien jakamista.

Kaikki oikeudet, joitakäyttäjät tarvitsevattyönsä tekemiseen, tuleehakea manuaalisesti jon-kin henkilön toimesta.

Työaikaa kuluu sellais-ten käyttöoikeuksienhakemiseen, jotka voi-taisiin mahdollisestimallintaa roolimalleihinja/tai automatisoida.

R

2 Vain yhdel-le henkilöllekerrallaan voi-daan hakeaoikeuksia.

Kaikille samoissa työ-tehtävissä/rooleissatyöskenteleville henki-löille tulee tehdä samatkäyttöoikeuspyynnöt.

Työaikaa kuluu, kun tar-vitsee tehdä samat käyt-töoikeuspyynnöt useallehenkilölle vaikka he suo-rittavat samoja työteh-täviä/roolia.

R

3 Vain yksi oi-keus kerrallaanvoidaan hakeaoikeuksia.

Jokainen käyttöoikeus-pyyntö tarvitsee avataerikseen.

Työaikaa kuluu, kunjokainen käyttöoikeus-pyyntö tarvitsee avataerikseen.

R

4 Käyttäjäteivät löydähaluamaansakäyttöoikeus-kohdetta

Käyttäjällä kuluuaikaa. Pääsynhallin-taprosessi saatetaan"ohittaa"suoralla palve-lupyynnöllä tiketöintijär-jestelmään. Puuttuvastakäyttöoikeuskohteesta eiilmoiteta kenellekkään.

Työaikaa kuluu. Tie-toturvariskit kasvavatjos kirjanpito jaetuistakäyttöoikeuksista onpuutteellista.

R & T

5 Käyttöoikeuksientoteutumisenkoetaan olevanhidasta.

Oikeuden saaja joutuuodottamaan ja ei pystysuorittamaan työtehtävi-ään järjestelmien osalta,joihin tarvitaan käyttöoi-keutta.

Työaikaa kuluu. R

6 Organisaatioyk-sikköihin pe-rustuvanroolitietokan-nan ylläpitoCIR:ssa eimahdollista.

Palveluiden omistajat jayksiköiden esimiehet jou-tuvat itse säilyttämääntietoa yksilölle tarpeelli-sista käyttöoikeuksista.

Ei yhtenäistä prosessiatai ohjetta yksikkökoh-taisten roolitietojen yllä-pitoon, jolloin tehtävieneriyttämistä ja pienim-män oikeuden tietotur-vaperiaatetta on vaikeanoudattaa ja valvoa.

T

38

Taulukko 6: Havaitut ongelmakohdat ARAP:ssa.

No. Ongelmakohta Toiminnallinen seuraus Liiketoiminnallinen vai-kutus

Luonne(R=resurssejatuhlaava,T=tietoturvaauhkaava)

1 Ei sääntöihintai automaa-tioon perus-tuvaa käyt-töoikeuksienjakamista.

Kaikki oikeudet tulee ha-kea manuaalisesti jonkinhenkilön toimesta.

Työaikaa kuluu käyttö-oikeuksiin, jotka voitai-siin mallintaa roolimal-leihin ja automatisoida.

R

2 Vain yhdel-le henkilöllekerrallaan voi-daan hakeaoikeuksia.

Kaikille samoissa työteh-tävissä työskentelevillehenkilöille tehdäänkäyttöoikeuspyynnötyksittäin.

Työaikaa kuluu, vaikkasamat pyynnöt useallehenkilölle.

R

3 Käyttäjärekisteriei automaat-tisesti poistavanhentuneitakäyttäjätilejä.

Järjestelmän ylläpitäjäntulee poistaa vanhentu-neet käyttäjätilit manu-aalisesti.

Työaikaa kuluu pois-toihin. Tietoturvariskitkasvavat, jos henkilötie-dot jostain syystä jäävätpoistamatta.

R & T

4 Tehtävieneriyttämi-nen (SoD)mahdollistakiertää.

Käyttöoikeuksien hake-miseen suunniteltua pro-sessia ohitetaan hyväk-synnän osalta.

Yrityksen tietoturva voiolla uhattuna, jos koor-dinaattorioikeudet jou-tuvat vääriin käsiin.

T

5 Haettavankohteen löytä-minen vaikeaa.

Käyttäjällä kuluu aikaa.Pääsynhallintaproses-si saatetaan ohittaapalvelupyynnöllä tike-töintijärjestelmään.

Työaikaa kuluu. Tie-toturvariskit kasvavatjos kirjanpito jaetuistakäyttöoikeuksista onpuutteellista.

R & T

6 Pyynnön to-teutuminen onhidasta.

Oikeuden saaja joutuuodottamaan ja ei pystysuorittamaan työtehtävi-ään.

Työaikaa kuluu. R

7 Organisaatio-yksikköihinperustuvanroolitietokan-nan ylläpito eimahdollista.

Käyttöoikeuksien ha-keminen työtehtävienmuuttuessa työlästä.

Puutteelliset kuvauksetorganisaatioyksiköidenoikeuksista.

T

39

6.8 Yhteenveto tapaustutkimuksesta

Tapaustutkimus paljastaa, että yrityksen pääsynhallinta on osittain puutteellisestitoteutettu, sillä pääsynhallintaa ei ole määritelty yrityksessä palvelutoiminnoksi eikäpääsynhallintaa johdeta minkään palvelukokonaisuuden toimesta. Lisäksi yhteisentoimintatavan kuvauksessa on suuria puutteita, eikä työntekijöille ole aina selvää,miten pääsyoikeuksia tulee yrityksessä hakea.

CIR:n ei koeta pystyvän vastaamaan yrityksen tämän hetkisiin liiketoimintata-paan ja -tarpeisiin. Saadut tulokset työkalusta tukevat koettua käsitystä. CIR onaikanaan toteutettu yrityksen sisäisten sovellusten hallintaan, mutta se ei kunnol-la pysty vastaamaan palvelutuotannon tarpeisiin. Skaalautuvuus on yksi isoimmis-ta ongelmakohdista, sillä nykyään ylläpidettävien järjestelmien määrä on suuri janiihin kohdistuu paljon muutoksia tiheällä aikavälillä. Myös käyttäjäkunta on mo-nimuotoisempaa kuin aikaisemmin, esimerkiksi ulkoisten työntekijöiden määrä onkasvanut ja vaihtuvuus lisääntynyt. Työkalu ei tue sääntöihin perustuvaa oikeuksienjakoa tai mahdollista automatisointia. Lisäksi roolitietokannan ja rooleihin perustu-van pääsynhallinnan toteuttaminen työkalussa ei ole mahdollista tai ainakin hyvinhankalaa. Pyynnön läpivientiajasta suurin osa menee muuhun kuin varsinaiseen oi-keuden toteuttamiseen.

Samoin kuin CIR:n, myöskään ARAP:n ei koeta pystyvän vastaamaan yrityksentämän hetkisiin liiketoimintatapaan ja -tarpeisiin. Saadut tulokset työkalusta tuke-vat koettua käsitystä. Myös ARAP:n yksi isoimmista ongelmista on skaalautuvuus,sillä henkilö- ja laiterekisteritietokannan hallinta ei kykene vastaamaan organisaa-tiossa tapahtuviin muutoksiin riittävän nopeasti ja tarkasti. Pyynnön läpivientia-jasta suurin osa menee muuhun kuin varsinaiseen oikeuden toteuttamiseen. Työkaluei tue sääntöihin perustuvaa oikeuksien jakoa tai mahdollista automatisointia, eikäroolitietokannan ja rooleihin perustuvan pääsynhallinnan toteuttamista. Lisäksi työ-kalussa on tietoturvapuutteita, joista suurimmaksi nousee SoD:n kiertomahdollisuus.

40

7 Pääsynhallinnan toteutusehdotus

Tässä kappaleessa esitellyn toteutusehdotuksen tarkoituksena on tarjota kattava ko-konaiskuvaus siitä, miten pääsynhallinta voitaisiin Atos IT Solution and Services Oy-yrityksessä toteuttaa. Tavoitteena on kuvata pääsynhallinta siten, että se voitaisiinmäärittää yrityksen yhdeksi palvelutoiminnoista ja että se lisäisi osaltaan yrityk-sen tietoturvaa ja tehostaisi käyttöoikeuspyyntöjen hallintaa ja toteutusta. Esitellyttoteutusehdotukset ja kuvaukset on tehty osana diplomityötä perustuen teoriao-suudessa esiteltyihin ratkaisuihin ja käytäntöihin siten, että ne soveltuvat Atos ITSolutions and Services yrityksen tarpeisiin. Kaikkien esiteltyjen kuvien tekstit ovatenglanniksi, sillä kuvat luotiin yrityksen käyttöön ja yrityksen työkielenä käytetäänenglantia. Kaikki esitellyt taulukot on diplomityössä esitelty suomeksi.

IT-ulkoistuspalveluita tarjoavan yrityksen toimintaan soveltuvan pääsynhallin-nan toteutusta lähdettiin suunnittelemaan laatimalla vaatimusmäärittely toteutuk-selle. Vaatimusmäärittely laadittiin, jotta saataisiin kehys ratkaisun tavoitteista javaatimuksista, sekä kuvaus, miten ratkaisun tulisi toimia ja millä keinoilla toimin-nallisuudet saavutetaan. Vaatimusmäärittelyn sisältämien asioiden lisäksi toteutus-ta suunniteltiin luvussa 1.3 esiteltyjä arviointikriteereitä silmällä pitäen.

Pääsynhallinta määriteltiin olevan yksi palvelutoiminnoista IT palveluorganisaa-tiossa. Sen toiminta kuvattiin prosessiksi sisältäen myös vastuualueiden määrittelyt.Pääsynhallintamenetelmäksi valittiin luvussa 5.4 esitelty roolipohjainen pääsynhal-linta, tukien kuitenkin luvussa 5.2 esitellyn harkinnanvaraista pääsynhallinnan mu-kaista toimintatapaa, jossa kohdejärjestelmille on määritelty pääkäyttäjä.

Teknistä toteutusta varten pääsynhallinnalle oli ennalta valittu työkalu, jollayrityksen pääsynhallinta suunniteltiin toteutettavan. Työkalulle ei kuitenkaan ollutmääritelty toiminnallisia vaatimuksia, rajapintakuvauksia eikä provisiointiratkaisu-ja, jotka ovat pakollisia työkalun kon�guroimisen ja käyttöönoton kannalta. Työka-lulle tehtiin toiminnallinen vaatimusmäärittely ja havainnekuva, jolla pyrittiin ku-vaamaan toiminnallisuuden kannalta oleelliset toiminnot ja rajapinnat. Lisäksi mää-riteltiin käyttöoikeuksien provisiointiratkaisut ja arvioitiin työkalun soveltuvuuttaniiden toteuttamiseen.

7.1 Toteutuksen vaatimusmäärittely

Osana diplomityötä pääsynhallinnan toteutuksehdotukselle tehtiin vaatimusmäärit-tely. Vaatimusmäärittely perustuu yrityksen tarpeeseen tarjota keskitettyä pääsyn-hallintaa tietoturvallisesti suurelle määrälle käyttäjiä, ottaen huomioon kohdejär-jestelmiin kohdistuvien muutosten tiheys. Lisäksi otettiin huomioon nykyisistä työ-kaluista havaitut ongelmakohdat, joiden koettiin oleellisesti uhkaavan tietoturvaatai hidastavan pääsynhallintaprosessia. Vaatimuksille määriteltiin nimi, kuvaus japrioriteetit. Vaatimusmäärittelyllä asetettiin yleiset reunaehdot, jotka valitun toteu-

41

tusratkaisun tulee toteuttaa. Vaatimusten prioriteettien nimien lyhenteen ja niidenkuvaukset on löytyvät taulukosta 7.

Taulukko 7: Vaatimusten prioriteetit.

Lyhenne Nimi KuvausP Pakollinen Vaatimus on välttämätön toteutuk-

sen kannalta.T Tärkeä Vaatimus tuo huomattavaa lisäarvoa

toteutukselle, mutta ei ole välttämä-tön.

A Ajan salliessa Vaatimus ei ole toiminnallisuudenkannalta oleellinen, mutta kannatta-va toteuttaa myöhemmässä vaihees-sa.

E Ei toteuteta Vaatimus ei ole tärkeä, eikä sitä kan-nattava toteuttaa nykyisen tiedonvalossa.

- Ei priorisoitu Vaatimukselle ei asetettu prioriteet-tia.

42

Vaatimukset sisältävät niiden nimen lisäksi lyhyen kuvauksen, mitä vaatimuk-sella tarkoitetaan, tai mitä sillä on tarkoitus saavuttaa. Vaatimukset ja niiden prio-riteetit määriteltiin siten, että toteutusratkaisu toteutuessaan parantaisi oleellisestipääsynhallintaa yrityksessä verrattaessa nykyiseen toteutukseen. Lisäksi toteutuk-sen tulee pystyä vastaamaan jollain tasolla myös tulevaisuuden tarpeisiin. Vaatimuk-set ja niiden prioriteetit on kuvattu taulukkoon 11 (liite B). Diplomityössä esiteltyvaatimusmäärittely sisältää ylätason vaatimukset toteutusratkaisulle.

7.2 Pääsynhallinta palvelutoimintona

Pääsynhallinta määriteltiin olevan yksi palvelutoiminto IT palveluorganisaatiossa,jolle tulee luoda prosessikuvaus. Määrittelyssä pyrittiin täyttämään luvussa 2 esitel-lyt palveluhallinnan päätavoitteet, joita ovat: palvelun sovittaminen sekä yrityksenettä asiakkaiden nykyisiin ja tuleviin tarpeisiin, parantaa tuotettujen palveluidenlaatua ja niistä saatua kokemusta ja vähentää palvelun ylläpitämiseen vaadittaviakustannuksia. Kuten luvussa 2.1 mainitaan, jotta toimintatavalle voidaan myöhem-min hakea serti�ointia, tulee sen olla linjassa alan parhaiden käytäntöjen kanssa.Pääsynhallinnan prosessikuvaus suunniteltiin perustuen yrityksen yleiseen palvelu-toimintaan ja ITIL v3 kuvaukseen [1, s. 68-71] pääsynhallinnasta. Diplomityössäesitelty pääsynhallintaprosessi on kuvattu ylätasolla kuvaan 13. Kuva tehtiin osanadiplomityötä ja sen perustana käytettiin ITIL v3 kuvausta pääsynhallinnasta.

43

Kuva 13: Pääsynhallinnan ylätason prosessikuvaus

44

Kuten luvussa 2 mainitaan, pääsynhallinta voidaan lukea osaksi palveluntoimi-tusprosesseja. Pääsynhallinnan päätoimintoja ovat käyttöoikeuspyyntöjen hallintaja jaettujen käyttöoikeustietojen ylläpito. Varsinaisten käyttöoikeuspyyntöjen hake-misen prosessi kuvataan kappaleessa 7.3 Käyttöoikeuspyyntöjen prosessikuvaus.

Luvussa 2 esiteltyjen palvelutoiminnan päätavoitteiden mukaisesti palvelut tuleesovittaa oman liiketoiminnan ja asiakkaiden tarpeiden mukaisesti. Asiakaskohtaisetprosessit (Customer Processes), politiikat ja määräykset tulee ottaa huomioon to-teuttaessa pääsynhallinnan toimintoja asiakkaalle.

Tietoturvan hallinta (Information Security Management) tarjoaa turvallisuus- jatietosuojapolitiikan, jota pääsynhallinnan tulee noudattaa [1, s. 68]. Sillä on myösrooli luvattomien pääsyjen tunnistamisessa ja vertailemisessa niitä käyttöoikeuksiin,joita pääsynhallinnan kautta on toimitettu.

Palveluiden suunnitteluvaiheessa (Service Design) tulee määritellä rooli- ja käyt-töoikeustiedot, jotta pääsynhallinta voidaan tehokkaasti toteuttaa palvelulle [2].Lisäksi palveluiden muutosprosessit (Service Transition), kuten muutostenhallin-ta (Change Management) ja kon�guraation hallinta (Con�guration Management)tarjoavat pääsynhallinnalle tietoa ympäristöjen muutoksista ja mahdollisuuden tie-dustella ympäristöissä olemassa olevia käyttöoikeustietoja [1, s. 69].

Käyttöoikeuspyyntö voi lähteä liikkeelle palvelupyyntöjen käsittelyprosessin kaut-ta (Request Ful�llment) Service Deskistä tai varsinaisesti käyttöoikeuspyynnöilletarkoitetusta työkalusta. Vastaavasti myös pyyntöjen toteutus voidaan siirtää to-teutettavaksi palvelupyyntöjen käsittelyprosessille, tai se voidaan toteuttaa osanakäyttöoikeuspyyntöjen hallintaa. Tieto jaetuista käyttöoikeuksista toimitetaan oi-keuden pyytäjälle ja saajalle, sekä tarvittaessa kaikille asiaankuuluville prosesseilleja asiakkaille.

Pääsynhallintaan liittyy myös muutamia tukitoimintoja, jotka pääsynhallinnanpalvelutoiminnassa tulee ottaa huomioon:

• Henkilöstömuutosten seuraaminen: kaikki työnkuvaa muuttavat toimenpiteet,kuten työtehtävien vaihto, ylennykset, irtisanoutumiset ja erottamiset käyn-nistävät toimintoja pääsynhallinnassa. Tieto muutoksista tulee yleisesti hen-kilöstöhallinnasta tai esimiehiltä.

• Roolien hallinta: Erillinen palvelutoiminto, jota pääsynhallinta ohjaa. Roolienhallinta on vastuussa roolitietokantaan tietojen keräämisestä, määrittelemises-tä ja ylläpitämisestä.

• Säännöllinen arviointi: Roolitietoja, käyttöoikeuskohteita ja niihin liitettyjähyväksyjiä tulee arvioida säännöllisesti, jotta ne ovat sopivia niille määritel-lyille palveluille.

45

• Käyttöoikeustietojen auditointi: Käyttöoikeustietojen auditoinnilla ja pyri-tään varmistamaan, että oikeudet on jaettu oikeille henkilöille ja niitä käy-tetään oikein.

• Jatkuva palvelun kehitys: Palvelun toimintaa tulee jatkuvasti kehittää, jottase vastaa yrityksen liiketoiminnallisiin tarpeisiin.

7.3 Käyttöoikeuspyyntöjen prosessikuvaus

Osana diplomityötä käyttöoikeuspyyntöjen käsittelyn vaiheista, vuorovaikutuksistaja vastuualueista tehtiin prosessikuva 14. Prosessikuvaus tarvitaan, jotta voidaanmääritellä käyttöoikeuspyyntöihin liittyvät toiminnot ja niiden vastuualueet otta-matta kantaa itse toteutuksessa käytettävään työkaluun. Luotu käyttöoikeuspyyn-töjen prosessikuvaus on suuntaa antava kuvaus, jota voidaan soveltaa tapauskohtai-sesti erilaisiin käyttöoikeuspyyntöihin ja jota voidaan käyttää apuna määriteltäessätyökalua käyttöoikeuspyyntöjen hallintaan.

46

Kuva 14: Käyttöoikeuspyyntöjen prosessikuvaus

Käyttöoikeuspyyntö lähtee liikkeelle pyynnön luomisesta pyytäjän toimesta. Pyyn-töjen vastaanottamisesta ja hallinnasta on vastuussa pääsynhallinta. Tämän lisäksipääsynhallinta vastaa myös pyytäjän ja oikeudensaajan todentamisesta, valittavienkäyttöoikeuskohteiden ja roolien toimittamisesta, olemassa olevien ja ristiriitaistenoikeuksien ja roolien tarkistamisesta sekä hyväksyjien valinnasta.

Toimintojen toteuttamiseen pääsynhallinta saa syötteitä muilta palvelutoimin-noilta: henkilötietoja henkilöstöhallinnalta, käyttöoikeus- ja roolitietoa roolienhal-linnalta ja kohdejärjestelmätietoa kon�guraation hallinnalta. Oikeuden pyytäjä vas-taa halutun käyttöoikeuskohteen ja oikeuden valinnasta pyyntöön.

Hyväksyjien määrittelyn jälkeen pyyntö ohjautuu vähintään kahdelle hyväksy-jälle hyväksyttäväksi, joita yleensä ovat oikeuden saajan esimies ja käyttöoikeuskoh-

47

teen pääkäyttäjä tai palvelun palveluomistaja. Hyväksynnän jälkeen pyyntö siirtyytuotannolle, joka vastaa oikeuden toteuttamisesta, pyynnön sulkemisesta ja toteu-tuksesta tiedottamisesta pyytäjälle ja oikeuden saajalle.

7.4 Identiteetinhallintamenetelmät

Koska yrityksessä on jo käytössä HR:n ylläpitämä henkilötietokanta, ei toteutuseh-dotuksen tarkoituksena ole korvata olemassa olevaa henkilötietokantaa. Lisäksi yri-tyksen verkkoidentiteettien ja verkkoresurssien hallintaa voidaan toteuttaa ActiveDirectoryn avulla.

Identiteetin tunnistaminen pääsy- ja käyttöoikeuksia hakiessa tulisi perustuaHR:n ylläpitämään henkilötietokantaan. Tällä tavalla pystytään todentamaan jatunnistamaan henkilön asema yrityksessä yksiselitteisesti. Identiteetin tunnistami-nen voitaisiin toteuttaa luvussa 4.1 mainitun jaetun paikallisen identiteetin mallinmukaisesti HR:n ylläpitämästä henkilötietokannasta.

Tunnistettuun identiteettiin tulisi pystyä lisäämään pro�ileja ja käyttövaltuuk-sia, jotta asianmukaista pääsynhallintaa voidaan toteuttaa. Toteutuksen tulee siisylläpitää henkilörekisteriä käyttäjistä, joihin pro�ileja ja käyttövaltuuksia voidaanliittää. Osa käyttövaltuuksista toteutetaan Active Directoryn kautta verkkoidenti-teettiin, jolloin toteutuksen pitää pystyä myös yhdistämään käyttövaltuuksia sisäl-tävä identiteetti sitä vastaavaan verkkoidentiteettiin.

Lopputuloksena on yrityksen sisällä toimiva luvussa 4.3 esitellyn yhdistetyn iden-titeetin mallin mukainen toteutustapa, jossa osapuolina toimivat HR:n ylläpitämähenkilötietokanta, Active Directory ja pääsynhallinnan ylläpitämä henkilötietokan-ta. HR:n henkilötietokanta tarjoaa henkilön todentamiseen yrityksessä tarvittavattiedot, ja sen pohjalta pääsynhallinta rakentaa oman henkilötietokantansa. Pääsyn-hallinnan henkilötietokannan identiteeteille voidaan liittää pro�ileja, roolitietoja jatietoja yksittäisistä pääsyvaltuuksista. Pääsyvaltuudet voivat koskea mitä tahansayrityksen ylläpitämää tietojärjestelmää ja resurssia. Pääsyvaltuudet, jotka koskevatActive Directoryn hallinnoimia resursseja, välitetään Active Directoryn verkkoiden-titeeteille.

Toteutustavan etuina on yksinkertaisuuden säilyttäminen olemassa olevissa jär-jestelmissä, tuoden kuitenkin identiteeteille lisähallittavuutta pro�ilien ja käyttöoi-keuksien muodossa. Lisäksi se mahdollistaa tehokkaan tavan kontrolloida käyttöoi-keuksia yhdestä pisteestä. Toteutus on myös modulaarinen, mahdollistaen uusienidentiteettirekisterien liittämisen siihen ilman, että se vaikuttaa olemassa olevienrekisterien toimintaan ja palveluihin.

48

7.5 Pääsynhallintamenetelmät

Jotta pääsynhallinta olisi osa luotettua tietojenkäsittelypohjaa (TCB), tulee sen toi-mia ylätason Reference Monitorina, kertoen identiteetteihin liitetyt pääsyvaltuudet,jota vasten voidaan kunkin identiteetin todelliset pääsyoikeudet tarkistaa. Lisäksisen tulee tarjota rajapinta käyttöoikeuspyyntöjen luomista varten sisältäen identi-teetin tunnistamisen ja varmistamisen.

Toteutuksen tulisi perustua luvussa 5.2 esiteltyyn harkinnanvaraisen pääsynhal-linnan malliin, sillä yrityksen lähes kaikki kohdejärjestelmät on määritelty resurssi-omistajuus mallin mukaisesti. Tämän lisäksi, tehostaakseen yleisten käyttöoikeuk-sien jakamista, pääsynhallinnan tulisi tukea luvussa 5.4 esitellyn roolipohjaisen pää-synhallinnan (RBAC) mukaista toimintatapaa. RBAC -menetelmän ei tarvitse to-teutuksessa sulkea pois DAC -menetelmää, vaan luodut roolit voidaan myös ajatellaresursseina ja näin määritellä niille omistaja resurssi-omistajuus mallin mukaisesti.

Koska kohdejärjestelmien käyttäjäkunta on suuri ja käyttäjien ja kohdejärjestel-mien vaihtuvuus tiheää, tulee pääsynhallinnan perustua ehdottomasti suljettuunDAC menetelmään. Tällöin pääsy sallitaan vasta, kun pääsylle löytyy positiivi-nen valtuutus kohdejärjestelmään. DAC menetelmän haittapuolena pidetty käyt-töoikeuksien harkitsematon leviäminen pyritään estämään noudattamalla yrityksentietoturvapolitiikan mukaista neljän silmän periaatetta pääsyvaltuuksien hyväksyn-nöissä. Tällä tavoin pelkästään resurssien omistajat eivät voi myöntää valtuuksiaresurssiin ja toteutus noudattaa luvussa 3.1.1 esiteltyä tehtävien eriyttämisen tieto-turvapolitiikkaa.

7.6 Roolien määrittely

Roolien hallinnan määriteltiin olevan erillinen palvelutoiminto, kuuluen kuitenkinpääsynhallinnan alaisuuteen. Roolien hallinnan tehtävä on kerätä, määritellä ja yl-läpitää roolitietokantaa ja niihin liittyviä oikeuksia. Roolien määrittelyssä pyrittiinottamaan huomioon luvussa 3.1.2 esitelty tietoturvapolitiikka, pienimmän oikeudenperiaate, säilyttäen kuitenkin käytännöllisyys ja oikeuksien riittävä kattavuus.

Osana diplomityötä tehtiin kuvaus roolien mallintamiselle yrityksessä. Lähtö-tason roolit määriteltiin kuvan 15 mukaisella tavalla, tavoitteena määritellä ylei-set tasot rooleille ja pystyä vastaamaan suureen määrään yleisluonteisia käyttöoi-keuspyyntöjä. Roolien määrittelyssä käytettiin luvussa 5.4.1 esiteltyjä top-down jabottom-up menetelmiä. Top-down lähestymistavassa roolit määriteltiin toiminnallis-ten yksiköiden perusteella. Bottom-up menetelmällä kerättiin muodostetuille rooleil-le olemassa olevat ja tarpeelliset oikeudet. Olemassa olevien ja tarpeellisten oikeuk-sien kerääminen toteutettiin haastattelemalla yksiköiden esimiehiä ja täyttämällätiedot keräämistä varten luotuun kaavakkeeseen (liite A).

49

Kuva 15: Roolien lähtötason määrittelemisessä käytetty malli

Pienimmiksi toiminnallisiksi yksiköiksi valittiin yrityksen organisaatioyksiköt.Kuvassa 15 näitä kuvataan tiimeillä Team 1 :stä Team 5 :een. Organisaatioyksiköi-den käyttöön päädyttiin niiden sopivan koon, tunnistettavuuden ja määrän vuoksi.Lisäksi sääntöihin perustuva roolien liittäminen identiteetteihin onnistuu parhaitenorganisaatioyksiköiden perusteella.

Palveluiden omistajien ja tiimien esimiesten katsottiin tarvitsevan hyvin saman-laisia oikeuksia keskenään, niinpä heille määriteltiin yleinen esimiestason rooli. Ul-koisille työntekijöille ja partnereille määriteltiin vain muutamia alustavia rooleja,joiden katsottiin kattavan suurimman osan heidän tarvitsemistaan käyttöoikeuksis-ta.

Yrityksen sisäisille työntekijöille, ulkoisille työntekijöille ja partnereille määri-teltiin yleiset peruskäyttöoikeudet sisältävät roolit. Peruskäyttöoikeudet sisältävätroolit eivät kata varsinaisiin työtehtäviin liittyviä oikeuksia, vaan yhteisiin työkalui-hin, palveluihin ja tietueisiin liittyviä oikeuksia.

Roolien hallinta tukee muidenkin kuin organisaatioyksikköperustaisten roolienluomista. Periaatteessa mistä työnkuvasta tahansa voidaan luoda rooli, jos sille mää-ritellään yhdessä tietoturvahallinnon kanssa vastuuhenkilö, joka vastaa roolin sisäl-löstä ja toimii hyväksyjänä roolille. Esitellyt lähtötason roolit pyrkivät vastaamaansuureen määrään yleisluontoisia käyttöoikeuspyyntöjä. Lisäksi jokaiselle käyttäjällevoidaan hakea mitä tahansa luotua roolia tai yksittäistä käyttöoikeutta. Oikeuden

50

hyväksymisestä vastaavat hyväksyjät.

7.7 Työkalun määrittely

Työkaluksi toteutukselle yritys oli ennalta valinnut DirX tuoteperheen. Työkalunvalintaan on vaikuttanut muun muassa se, että työkalu on yrityksen omistama jasen käytöstä on paikallista kokemusta yhteiskäyttötunnusten tietojen säilyttämises-sä. Lisäksi muokattavuuden sekä modulaarisen rakenteen vuoksi toiminnallisuus jarajapinnat voidaan määritellä paikallisiin tarpeisiin sopivaksi.

Työkalun käyttöönottoa varten tehtiin toiminnallinen määrittely, jolla kuvat-tiin toteutuksen kannalta tarvittavat toiminnallisuudet ja rajapinnat, joita työka-luun tarvitsee toteuttaa. Lisäksi määriteltiin työkaluun toteutettavat provisointita-vat. Varsinainen tekninen toteutus ja työkalun käyttöönotto jätettiin tutkimustyönulkopuolelle.

7.7.1 DirX

DirX on Atoksen omistama tuoteperhe, jolla voidaan tarjota keskitetty identiteetin-ja pääsynhallinta yrityksille [34]. Tuoteperheeseen kuuluu neljä keskeistä tuotetta[34]:

• DirX Identity, tarjoaa automatisoidun käyttäjien ja käyttöoikeuksien hallin-taan ja jakamiseen tarkoitetun järjestelmän.

• DirX Audit, tarjoaa keskitetyn alustan käyttöoikeustietojen keräämiselle, va-rastoinnille ja analysoinnille.

• DirX Directory, mahdollistaa turvallisen varastoinnin digitaalisille identitee-teille ja on suunniteltu käsittelemään hyvinkin suuri määrä käyttäjiä.

• DirX Access, mahdollistaa luvun 4.3 mukaisen yhdistetyn identiteetin ja ker-takirjautumismenetelmän luomisen järjestelmiin tarjoten samalla turvameka-nismeja luvattomien pääsyjen estämiseksi.

Tässä diplomityössä ei erikseen eritellä millä tuoteperheen tuotteella mikäkintoteutuksen osa on tarkoitus toteuttaa, vaan puhutaan yleisesti DirX:stä tai IAM-työkalusta.

7.7.2 IAM-työkalun toiminnallisuuden määrittely

Työkalun toiminnallinen määritelmä tehtiin perustuen luvussa 7.1 esiteltyyn pää-synhallinnan vaatimusmäärittelyyn ja työkalun käytöstä yhteiskäyttötunnusten tie-tojen säilyttämisessä saatuun kokemukseen. Toiminnallisuuden määrittely jaettiin

51

osiin: rajapinnat ja tietolähteet sekä toiminnot. Toiminnallisuudesta tehtiin diplomi-työn puitteissa havainnekuva, kuva 16, jossa rajapinnat ja tietolähteet on merkattuI1:stä I4:ään ja toiminnot sinisiin laatikoihin ja nuoliin.

Kuva 16: DirX toiminnallisuuden kuvaus

52

Rajapinnat ja tietolähteet määrittelevät mitä tietoa työkalulle tarvitsee antaa,miksi ja mistä tieto saadaan. Rajapintamääritys ei kuitenkaan ota kantaa mitenvarsinainen tiedonsiirto toteutetaan.

I1: Käyttäjätieto yrityksen HR-järjestelmästä. Tiedon perusteella työkaluun synk-ronoidaan paikallinen käyttäjärekisteri, joka vastaa HR:n ylläpitämää tietoa.Tiedot luetaan päivittäin ja käyttäjien lisäykset ja poistot tehdään automaat-tisesti perustuen luettuun tietoon. Tiedon tulee sisältää riittävästi tuntomerk-kejä käyttäjistä, kuten yksilöllinen henkilönumero, organisaatioyksikkö ja esi-mies, jotta heidät voidaan tunnistaa ja jotta heille voidaan määritellä roolit jaesimieshyväksyjät.

I2: Kohdejärjestelmätieto yrityksen CMDB:stä (kon�guraatiotietokanta). Tiedonperusteella työkaluun kerätään kohdejärjestelmät ja haettavat käyttöoikeu-det. Tarpeettomat kohdejärjestelmät karsitaan pois vertaamalla haettua tietoamääriteltyyn mustaan listaan. Kohdejärjestelmien tuntomerkkien tietojen pe-rusteella kohdejärjestelmät voidaan määritellä kuuluvaksi osaksi tiettyä rooliaja määritellä siihen jaettavien oikeuksien provisiointikanava.

I3: Oikeuksien toteutustieto IAM-työkalusta oikeaan provisointikanavaan. Provi-sointi voi olla toteutettu esimerkiksi tiketöintijärjestelmän kautta, jolloin haet-tavasta oikeudesta avataan palvelupyyntö oikealle toteutustiimille.

I4: Toteutuksen tilatiedot provisointikanavasta IAM-työkaluun. Jos oikeus provi-sioidaan muuten kuin suoraan kohdejärjestelmään, esimerkiksi sähköpostinatai tiketöintityökalun kautta, tulee toteutuksen etedistymisestä saada tilatie-dot takaisin IAM-työkaluun. Toteutuksen onnistumisesta tarvitaan kuittaus,jotta oikeus voidaan merkitä toimitetuksi käyttäjälle.

Toiminnot määrittelevät mitä työkalun tulee pystyä tekemään siihen syötetylläja määritellyllä tiedolla. Määritelmäkuvaukset eivät ota kantaa siihen, miten toimin-nallisuus varsinaisesti työkaluun toteutetaan.

Kohdejärjestelmätiedon tulkitseminen käyttöoikeuskohteiksi. Kohdejärjestelmätietopuretaan auki ja perustuen järjestelmien tuntomerkkeihin jaetaan rooleihin jakäyttöoikeuskohdelistaukseen haettaviksi kohteiksi. Tuntomerkkien perusteel-la asetetaan myös provisiointikanava kohteille.

Roolien mallintaminen käyttäjille. Käyttäjille osoitetaan roolit automaattises-ti perustuen käyttäjien tuntomerkkitietoihin. Roolitieto lasketaan auki oikeuk-siksi ja käyttäjän olemassa olevia oikeuksia verrataan roolitietojen sisältämiinoikeuksiin. Haettavista oikeuksista luodaan esihyväksytyt oikeuspyynnöt, jossaesihyväksyntä perustuu oikeuden saamiseen roolin kautta. Vastaavasti käyttä-jän itse hakiessa roolia, puuttuvista oikeuksista lähetetään hyväksyntäpyyntöesimiehelle ja kohdejärjestelmien palveluomistajille.

Oikeuksien aukilaskenta ja provisiointi. Haettavat käyttöoikeuskohteet jaotel-laan provisiointikanavan ja toteutustiimin perusteella ryhmiin ja tämän jälkeen

53

haettavat oikeudet tulkataan kullekin provisiointikanavalle soveltuvaan muo-toon ja siirretään provisioitavaksi. Provisiointikanavista saaduilla tilatietopäi-vityksillä pidetään kirjaa oikeuksien toteutuksen etenemisestä.

7.7.3 Oikeuksien provisiointi

Käyttöoikeuksien provisiointi suunniteltiin voivan toteuttaa kohdejärjestelmästä riip-puen neljällä eri tavalla: 1) suora liitäntä kohdejärjestelmiin, 2) liitäntä Active Direc-tory -hakemistopalveluun, 3) tiketöintijärjestelmän kautta tai 4) sähköpostiviestinavulla. Prosiviointisuunnitelmasta tehtiin diplomityön puitteissa havainnekuva 17.Työkalu mahdollistaa kaikkien näiden provisiointimenetelmien toteuttamisen. Useanprovisiointikanavan käyttäminen lisää vikasietoisuutta, sillä oikeuksien toteuttami-nen ei ole riippuvainen yhdestä provisiointikanavasta. Lisäksi se mahdollistaa op-timaalisimman provisointikanavan käyttämisen kohdejärjestelmäkohtaisesti, jolloinoikeuksien toteuttaminen on mahdollisimman tehokasta. Toisaalta, usean provisioin-tikanavan toteuttamisessa ja käyttämisestä on myös haasteita, sillä usean provisoin-tikanavan toteutus työkaluun vaatii paljon työtä toteutuksellisesti ja ylläpidollisesti.

Kuva 17: Oikeuksien provisiointikanavat

54

1. Suora liitäntä kohdejärjestelmiin.Kaikkein tehokkain tapa oikeuksien saa-misen kannalta on provisioida oikeuksia suoraan kohdejärjestelmään. TällöinIAM-työkalu määrittää välittömästi oikeuden hyväksynnän jälkeen kohdejär-jestelmään, kenellä on sinne tietyllä oikeustasolla pääsy. Myös oikeuksiin ta-pahtuvat muutokset, kuten tunnuksien lukitsemiset ja poistot, tapahtuvat vä-littömästi ja näin parantavat tietoturvaa. Suora liitäntä kohdejärjestelmiinmahdollistaa myös hyvin ajantasaisen ja tarkan tiedon siitä, kenellä on oi-keuksia mihinkin järjestelmään. Ongelmana suorassa liitännässä on liitäntä-työn määrä. Lähes jokainen kohdejärjestelmä joudutaan liittämään erikseenja liitäntöjen rajapintamääritykset voivat vaihdella kohdejärjestelmien välillä.Tiheästi muuttuvissa ympäristöissä vaadittu työmäärä suorien liitäntöjen te-kemiseen ei ole kannattavaa verrattaessa saatuun hyötyyn, vaan liitännät tulisirajata ympäristöihin, joissa tapahtuu vähän muutoksia, mutta joissa on suurikäyttöaste.

2. Active Directory. Liitäntä hakemistopalveluun, kuten Microsoft Active Di-rectoryyn, tuo hyvin samanlaiset hyödyt kuin suora liitäntä kohdejärjestelmiin.IAM-työkalu määrittää pääsyoikeudet ja niiden tasot Active Directoryn käyt-täjätietokantaan ja hakemistopalveluun mahdollistaen tehokkaan pääsyoikeuk-sien jakamisen siihen kuuluville käyttäjille. Oikeuksien toteutuminen tapahtuuvälittömästi, samoin niihin kohdistuvat muutokset. Liitäntä hakemistopalve-luun mahdollistaa hyvin ajantasaisen ja tarkan tiedon toteutetuista oikeuksis-ta eri järjestelmiin. Liitännät tarvitsee tehdä vain käytössä oleviin Active Di-rectory hakemistopalveluihin, jolloin liitäntöjen määrittämiseen ja tekemiseenvaadittu työmäärä ei kasva suureksi. Ongelmana Active Directory liitäntöjentekemisessä on, että se vaatii vahvan luottamussuhteen IAM-työkalun ja siihenliitettyjen hakemistopalveluiden välille. Liitäntä voi olla vaikea saada hyväk-syttyä Active Directoryihin, joilla hallinnoidaan asiakasympäristöjä. Lisäksisuuri määrä kohdejärjestelmiä ei ole liitetty Active Directoryyn, kuten Unix-järjestelmät ja SAP-ympäristöt. Tällaisiin järjestelmiin oikeuksien provisiointitarvitsee toteuttaa muulla tavalla.

3. Tiketöintijärjestelmä Oikeuksien provisiointi tiketöintijärjestelmään mah-dollistaa pääsyoikeuden toteuttamisen lähes mihin tahansa kohdejärjestelmään,mikä tekee siitä vikasietoisen provisiointitavan. Perustuen kohdejärjestelmäntukiryhmään, IAM-työkalu luo pyydetystä oikeudesta palvelupyynnön tike-töintijärjestelmään oikealle toteutustiimille varsinaiseen toteutukseen. Liitän-tä tiketöintijärjestelmään ei tarjoa välitöntä oikeuden toteutusta, mutta sääs-tää kuitenkin manuaalista työtä palvelupyynnön luomisessa. Lisäksi pyyntövoi kohdistua järjestelmään, joka ei olisi muuten mahdollista liittää IAM-työkaluun. Ongelmana tiketöintijärjestelmän käytössä on työmäärä, joka tar-vitaan kohdejärjestelmien tukiryhmätietojen tarkistamiseen ja oikeiden toteu-tustiimien määrittämiseen niille. Eri kohdejärjestelmiä koskevat pääsyoikeudettulee pystyä ohjaamaan oikeille toteutustiimeille. Lisäksi oikeuden varsinainentoteutus vaatii aina manuaalista työtä toteutustiimiltä. Provisiointi tiketöin-tijärjestelmään ei myöskään takaa ajantasaista ja täydellistä varmuutta käyt-

55

täjien pääsyoikeustietojen todellisesta tilasta.

4. Sähköposti IAM-työkalun kon�guraation määrittämisen ja sen ylläpitämisenkannalta helpoin tapa provisioida oikeuksia on lähettää niiden tiedot sähkö-postilla Service Deskiin. IAM-työkalu luo haetuista oikeuksista viestin, jokasisältää tiedon siitä, millaiset oikeudet tarvitaan, mihin ja kenelle. Viesti lä-hetetään Service Deskiin, joka tulkitsee viestin ja luo siitä palvelupyynnöntiketöintijärjestelmään. Sähköpostin käyttö on hyvin vikasietoinen provisioin-titapa sen yksinkertaisuuden vuoksi ja sillä voidaan hakea oikeutta lähes mi-hin tahansa kohdejärjestelmään. Ongelmana sähköpostiliitännässä on, ettei setarjoa mitään automaatiota ja oikeuksien toteutuksen kannalta parannustaverrattaessa yrityksen olemassa oleviin käyttöoikeuspyyntöjen hallintaratkai-suihin. Manuaalinen työmäärä säilyisi edelleen Service Deskissä ja toteutus-tiimissä. Oikeuksien provisiointi sähköpostiliitännän kautta ei myöskään takaaajantasaista ja täydellistä varmuutta käyttäjien pääsyoikeustietojen todellises-ta tilasta.

56

8 Arviointi, yhteenveto ja jatkotutkimus

Luvussa 7 esitelty toteutusehdotus arvioitiin vertailemalla sitä luvussa 6 käsiteltyyntapaustutkimukseen ja sen tuloksiin ja luvussa 1.3 esiteltyjä arviointikriteerejä vas-ten. Varsinaisesta teknisestä toteutuksesta ei ole tuloksia, sillä työkalun käyttöön-otto ei kuulunut tämän diplomityön rajaukseen.

8.1 Arviointi

Tapaustutkimuksesta saatujen tulosten perusteella yrityksen nykyinen pääsynhallin-nan toteutus on puutteellinen monelta osin. Toteutusehdotuksessa esitelty ratkaisutarjoaisi keskitetyn ratkaisun nykyisen kahden, osittain päällekkäin toimivan, työ-kalun tilalle. Käyttöoikeuksien hakemiselle voitaisiin luoda yksiselitteinen ohjeistusja toimintatapa. Lisäksi toteutusehdotus mahdollistaisi ajantasaisen identiteettienylläpitämisen sekä pro�ilien, roolien ja pääsyvaltuuksien liittämisen niihin. Toisinkuin ARAP:ssa ja CIR:ssä, toteutusehdotuksessa esitelty työkalu tukee roolipoh-jaista pääsynhallintaa ja automatisoitua, sääntöihin perustuvaa käyttöoikeuksien jaroolien jakamista.

Toteutusehdotuksen toteutuskelpoisuutta arvioitiin tarkastelemalla toteuttami-seen vaadittavia laite- ja ohjelmistoinvestointien sekä henkilöresurssien määrää jatoteutukseen kuluvaa aikaa. Toteutukseen valittu työkalu on yrityksen omistama jayritys tuottaa itse palvelimien ja palveluiden ylläpitotoimintoja, mistä johtuen to-teuttamiseen vaaditut ohjelmisto- ja laiteinvestoinnit ovat vähäiset, eivätkä ole es-teenä toteutukselle. Henkilöresurssien määrää ja toteutukseen kuluvaa aikaa tarkas-teltiin työkalun käyttöönottoa varten laaditun projektisuunnitelman pohjalta. Pro-jektisuunnitelman mukaan toteutus vaatisi noin 400 henkilötyöpäivää ja ajallisestiolisi mahdollista toteuttaa reilussa puolessa vuodessa. Arvio tarvittavien resurssienmäärästä ja aikataulusuunnitelmasta on kohtuullinen, vaadittu osaamistaso löytyysuurelta osin yrityksen sisältä, ja heidän saaminen projektin käyttöön on mahdol-lista. Toteutusehdotus on henkilö- ja aikaresurssien sekä investointien osalta toteu-tuskelpoinen yrityksen kokoon ja liikevaihtoon nähden.

Toteutusehdotuksen taloudellista kannattavuutta arvioitiin tekemällä laskelmasiitä, miten paljon säästöjä toteutuksella voidaan saavuttaa verrattaessa nykyiseentoimintatapaan. Kannattavuuslaskelma perustuu arvioihin, mitä toteutusehdotuk-sella oletetaan saavutettavan lyhyellä aikavälillä. Tavoitteena on saavuttaa projek-tiin käytetty työmäärä vuoden sisällä toteutuksesta. Arviota varten tutkimuksessatehtiin taulukon 8 mukaiset lähtöoletukset toteutukselle.

57

Taulukko 8: Lähtöoletukset, jotka toteutusehdotuksen oletetaan täyttävän

Nro. Olettamus1 80% Sharepoint pyynnöistä voidaan määritellä rooleihin, jolloin oikeuk-

sien hakemiseen ja hyväksymiseen ei kulu aikaa.2 30% Muista pyynnöistä voidaan määritellä rooleihin, jolloin oikeuksien

hakemiseen ja hyväksymiseen ei kulu aikaa.3 80% Sharepoint pyynnöistä provisioidaan AD:iin.4 20% Sharepoint pyynnöistä provisioidaan OSD:iin.5 5% Muista pyynnöistä provisioidaan joko AD:iin tai suoraan kohdejär-

jestelmiin.6 45% Muista pyynnöistä provisioidaan OSD:iin.7 50% Muista pyynnöistä provisioidaan sähköpostiin.8 Provisiointi AD:iin tai suoraan kohdejärjjestelmiin ei kuluta kenenkään

työaikaa.9 Provisiointi sähköpostiin kuluttaa Service Deskin ja tuotantotiimin työ-

aikaa samoin kuin CIR:n tapauksessa.10 Provisiointi sähköpostiin kuluttaa oikeuden saajan odotusaikaa samoin,

kuin CIR:n hyväksymisestä sulkeutumiseen kulunut aika.11 Provisiointi OSD kuluttaa tuotantotiimin työaikaa samoin, kuin ARAP:n

hyväksymisestä sulkeutumiseen kulunut aika.12 Provisiointi OSD kuluttaa oikeuden saajan odotusaikaa samoin, kuin

ARAP:n hyväksymisestä sulkeutumiseen kulunut aika.13 Oikeuden saajan odotusaika muutetaan menetetyksi työajaksi seuraaval-

la tavalla: odotusajan tunnit muutetaan viikoksi (tunnit/24/7), viikotmuutetaan työtunneiksi (viikot*37,5), 10% työtunneista katsotaan me-netetyksi työajaksi (tunnit*10%).

14 Neljän silmän periaatteen mukaisesti hyväksynnissä käytetään vähintäänkahta hyväksyjää. Hyväksyntään käytetty työaika kerrotaan kahdella.

15 Käyttöoikeuspyyntöjen hakemiseen ja hyväksymiseen kuluva aika on sa-ma, kuin ARAP:ssa ja CIR:ssa.

16 Pyynnöt joita ei jaeta automaattisesti vaan katsotaan haettavan manu-aalisesti manuaalisesti, kuluttavat oikeuden saajan odotusaikaa samallatavalla, kuin ARAP:n avaamisesta hyväksymiseen kulunut aika.

Tapaustutkimuksessa kerättyjen tulosten perusteella laskettiin käyttöoikeuspyyn-töihin käytetty työaika kuukautta kohden ARAP:n ja CIR:n osalta. Käytettyihintyöaikoihin laskettiin mukaan oikeuden saajan odotusajasta laskettu menetetty työ-aika olettamuksen nro. 13 mukaisesti. Taulukkoon 9 on laskettu ARAP:n ja CIR:nosalta käyttöoikeuspyyntöihin käytetty työaika kuukautta kohden. Yhteenlaskettu-na käyttöoikeuspyyntöihin kuluu arviolta 1520 h/kk.

58

Taulukko 9: Käyttöoikeuspyyntöihin käytetty aika ARAP:ssa ja CIR:ssä kuukauttakohden

ARAP CIRPyyntöjä keskimäärin kuukaudessaSharepoint 76Muut 109 73Käytetty työaika pyyntöä kohdenPyynnön avaamiseen 15 min 15 minPyynnön hyväksymiseen 5 min 5 minKoordinaattorin työ 15 minService Desk pyynnön vastaanotto ja tiketinluonti

5 min

Tuotantotiimi toteutus 15 min 15 minVastaanottajan menettämä työaika(olettamus 13)Avaamisesta hyväksymiseen 3,1 h 2,9 hHyväksymisestä sulkemiseen 1,1 h 2,9 hKäytetty työaika yhteensä:

91200 min1520 h

Toteutusehdotuksen mukaisen toimintatavan arvioitu käyttöoikeuspyyntöihin käy-tetty työaika on laskettu taulukkoon 10. Lasketussa arviossa käytetään taulukon 8mukaisia olettamuksia toteutuksesta.

59

Taulukko 10: Arvio toteutusehdotuksessa käyttöoikeuspyyntöihin kuluvasta ajasta

Arvio uudella työkalulla kuluvasta ajasta DirXKäytetty työaika avaamiseen ja hyväksymiseensekä vastaanottajan menettämä työaika80% Sharepoint pyynnöt (RBAC) 0 min20% Sharepoint pyynnöt (manuaaliset pyynnöt) 3311 min30% Muut pyynnöt (RBAC) 0 min70% Muut pyynnöt (manuaaliset pyynnöt) 27755 minHyväksymisen jälkeiset työvaiheet80% Sharepoint pyynnöt (AD provisiointi) 0 min20% Sharepoint pyynnöt (OSD provisiointi) 1205 min5% Muut pyynnöt (AD/suora provisiointi) 0 min45% Muut pyynnöt (OSD provisiointi) 6493,5 min50% Muut pyynnöt (Sähköpostiprovisiointi) 17700 minYhteensä:

56400 min940 h

Taulukoista 9 ja 10 voidaan laskea toteutusehdotuksen tuoma hyöty. Toteutuseh-dotuksen arvioidaan tuovan työaikasäästöä kuukaudessa 1520 h/kk - 940 h/kk = 580h/kk. Vertaamalla kuukausittaista hyötyä projektisuunnitelman arvioituun työmää-räarvioon, joka oli 400 henkilötyöpäivää, eli 3000 työtuntia, voidaan karkeasti ar-vioida toteutuksen takaisinmaksuajan työmäärän osalta olevan 3000 h / 580 h/kk= 5 kk.

Toteutusehdotuksen tuomaa työaikasäästöä tarkastellessa toteutusehdotus täyt-tää taloudellisen kannattavuuden kriteerin. Lisäksi toteutusehdotus tuo laadullistalisäarvoa yrityksen pääsynhallintaan muun muassa tarjoamalla tarkemman ja ajan-tasaisemman olemassa olevien käyttöoikeuksien tarkastelun, ja lisäämällä automaa-tiota ja tietoturvaa RBAC -mallin käyttöönoton myötä.

Toteutusehdotuksen ylläpidettävyyden ja käytettävyyden arvio perustuu aikai-sempaan kokemukseen DirX työkalusta. Työkalun ja siihen kon�guroidun sisällönylläpidettävyys ja päivitettävyys vaatii ylläpitäjältä tietyn tason osaamista työka-lusta. Toiminnot ovat kuitenkin hyvin johdonmukaisia ja selkeitä, ja työkalu ei tar-vitse päivittäisiä ylläpitotoimintoja. Riittää, että aika ajoin toiminnallisuus tarkis-tetaan ja tarvittaessa sisältöön tai toiminnallisuuteen pyydetyt muutokset toteute-taan. Työkalusta on olemassa paljon dokumentaatiota ja osaamista yrityksen sisällä,jolloin koulutusta on mahdollista tarjota uusille ylläpitäjille hyvinkin nopeasti. Lop-pukäyttäjän näkökulmasta käytettävyyttä voidaan muokata hyvinkin paljon. Lop-pukäyttäjät käyttävät työkalua web-portaalin kautta, joka on täysin muokattavissahaluttujen toiminnallisuuksien ja ulkoasun mukaan.

60

Turvallisuutta arvioitiin tarkastelemalla toteutusehdotuksen turvallisuuteen liit-tyviä ominaisuuksia. Toteutusehdotuksen avulla pystytään toteuttamaan dynaami-nen tehtävien eriyttäminen oikeuksien hakemisessa ja noudattamaan neljän silmänperiaatetta oikeuksien hyväksymisessä. RBAC -mallin käyttöönotto lisää osaltaantietoturvaa mahdollistaen ennalta määritellyt roolikuvaukset työntekijöille ja oi-keuksien jakamisen niihin perustuen. RBAC -mallin avulla saavutetaan luottamuk-sellisuus, eli tietoa luovutetaan vain heille, joilla on oikeus tietoon. Verrattaessa ta-paustutkimuksessa kuvattuihin ARAP:iin ja CIR:iin, toteutusehdotus tarjoaa useitatietoturvaa lisääviä ominaisuuksia, kuten ajantasaisen tiedon olemassa olevista käyt-töoikeuksista, yhtenevän käyttäjätietokannan HR:n kanssa, mahdollisuuden hakeakohdejärjestelmätiedot suoraan CMDB:stä ja nopeamman käyttöoikeuksien provi-sioinnin kohdejärjestelmiin. Nämä ominaisuudet takaavat tietoturvatavoitteiden mu-kaisen pääsynhallintatiedon saatavuuden, eheyden ja aitouden ja kiistämättömyy-den.

Skaalautuvuutta arvioitiin tarkastelemalla miten hyvin toteutusehdotus pystyyottamaan huomioon käyttäjäkunnan ja järjestelmien määrän ja niissä tapahtuvatmuutokset. Toteutusehdotus vastaa käyttäjäkunnan muutoksiin rakentamalla pai-kallisen käyttäjärekisterin tietokantaan yrityksen HR-järjestelmän tietojen pohjal-ta. Tiedot luetaan päivittäin ja käyttäjien lisäykset ja poistot tehdään automaat-tisesti perustuen luettuun tietoon. Verrattaessa tapaustutkimuksessa kuvattuihinARAP:iin ja CIR:iin, toteutusehdoksen käyttäjäkunnan hallinta on hyvin saman-kaltainen kuin CIR:ssä. Vastaavasti kuin käyttäjätietojen ylläpitäminen, kohdejär-jestelmätiedot voidaan lukea yrityksen CMDB:ia ja rakentaa sen pohjalta työkaluunoma kohdejärjestelmätietokanta. Tiedot voidaan määritellä luettavaksi päivittäinja lisäysten ja poistojen toteutus automatisoida. Verrattaessa tapaustutkimuksessakuvattuihin ARAP:iin ja CIR:iin, kohdejärjestelmien lukeminen CMDB:sta on huo-mattava parannus mahdollistamalla ajantasaisen kohdejärjestelmätiedon tuomisenpääsynhallinnan piiriin. Toteutusehdotuksessa esitelty työkalu DirX mahdollistaasuurienkin tietokantojen hallinnoimisen.

Toteutusehdotuksessa esitelty pääsynhallinta palvelutoimintona arvioitiin olevanlinjassa alan parhaiden käytäntöjen (ITIL v3, COBIT Guidance to Achieve Cont-rol Objectives for Successful IT Governance) kanssa. Toteutusehdotuksen mukaisellepääsynhallinnalle voidaan yrityksessä lähteä hakemaan standardien mukaista serti-�ointia.

8.2 Yhteenveto

Yleisesti pääsynhallinnan toteuttamiseen yrityksissä ei ole yhtä oikeaa toteutus-tapaa. Useissa tapauksissa toteutuksen suhteen tarvitsee tehdä kompromisseja te-hokkuuden, turvallisuuden, käytettävyyden, muokattavuuden ja kustannusten välil-lä. IT-ulkoistuspalveluntarjoajan näkökulmasta pääsynhallinnan tulee kyetä vastaa-

61

maan suureen määrään käyttäjiä ja erilaisia ympäristöjä säilyttämällä yrityksen tie-toturvapolitiikan määrittelemä tavoiteltu tietoturvataso. Jos pääsynhallinnalle pal-veluna halutaan hakea serti�ointia, tulee se kuvata palvelutoiminnoksi, joka on lin-jassa alan parhaiden käytäntöjen kanssa.

Tapaustutkimuksessa saaduista tuloksista voidaan todeta, että pääsynhallintavaatii aina jatkuvaa kehittämistä ja valvontaa, varsinkin, jos sen on tarkoitus pys-tyä vastaamaan yritysten tarpeisiin ympäristöjen ja käyttäjäkunnan muuttuessa.Lisäksi pääsynhallinnan toiminnallisuuden tulee olla selkeästi kuvattu ja dokumen-toitu, jotta toteutuksen arvioiminen ja koko prosessin auditoiminen olisi mahdollis-ta. Pääsynhallinnan huolellinen suunnittelu paitsi takaa tietoturvallisen tavan hallitakäyttäjien käyttöoikeuksia, myös nopeuttaa käyttöoikeuksien hakemiseen ja jakami-seen kuluvia toimenpiteitä, vähentää manuaalisen työn määrää, ja näin pienentääkoko yrityksen operatiivisia kustannuksia.

Esitelty toteutusehdotus pyrkii esittelemään kattavan kokonaiskuvan siitä, mi-ten pääsynhallinta voitaisiin toteuttaa IT-ulkoistuspalveluita tarjoavassa yritykses-sä. Toteutusehdotuksessa on otettu huomioon erityisesti tietoturvan takaaminenpääsynhallinnassa, ja pääsynhallinnan määritteleminen palvelutoiminnoksi. Toteu-tusehdotuksessa ei pyritä ratkaisemaan yksittäisten käyttöoikeuspyyntöjen mahdol-lisimman tehokasta toteuttamista, mutta esitellään roolipohjainen pääsynhallinta-menetelmä, jolla yksittäisten käyttöoikeuspyyntöjen määrää voitaisiin vähentää huo-mattavasti. Lisäksi toteutusehdotus esittelee reunaehdot, mitä teknisiä vaatimuksiavalitun työkalun tulisi toteuttaa ja miten ne voidaan saavuttaa. Arvioinnin perus-teella toteutusehdotus on yrityksen kannalta suositeltava toteuttaa, sillä se tarjo-aa paitsi tehokkaamman tavan toteuttaa pääsynhallintaa yrityksessä, mahdollistaamyös toimintatavan linjaamisen yleisten alan standardien mukaiseksi ja lisää osal-taan yrityksen tietoturvaa.

8.3 Kehitysehdotukset ja jatkotutkimus

Pääsynhallinnan toteuttaminen onnistuneesti IT-ulkoistuspalveluita tarjoavan yri-tyksen sisällä on jo sinällään iso haaste. Palveluiden myyminen asiakkaille on luon-nollisesti osa IT-ulkoistuspalveluita tarjoavan yrityksen ydinliiketoimintaa, jolloinpalveluiden suunnittelussa tulee myös arvioida niiden soveltuvuutta erilaisiin asia-kastarpeisiin. Kehitysehdotuksena pääsynhallintaan liitetty identiteetinhallinta yri-tyksen ja sen asiakkaiden välillä voitaisiin toteuttaa luvussa 4.3 mainitun yhdistetynidentiteetin mallin mukaisesti, ja rakentaa asiakaskohtainen pääsynhallintaratkaisutukemaan tätä mallia. Toteutuksessa tulee kuitenkin aina ottaa huomioon, että ku-ten luvussa 5.1 on mainittu, ei ole olemassa yhtä oikeaa pääsynhallintamenetelmää,vaan menetelmä tulee valita aina ympäristöön ja tietoturva- ja käytettävyysvaati-muksiin soveltuvaksi.

Käyttöoikeuspyyntöjen provisiointi vaatii usein tuotantotiimin osallistumisen oi-

62

keuksien toteutukseen. Oleellinen jatkotutkimuksen kohde yrityksen kannalta onprovisioinnin tehokkuuden arviointi. Tehokkuuden arvioinnilla voidaan tunnistaane käyttöoikeuskohteet, jotka vaativat eniten aikaa toteutuksessa. Lisäksi tulisi ar-vioida se, paljonko työtä vaatii provisioinnin toteuttaminen suoraan kohdejärjestel-miin tai Active Directoryyn, ja tämän tiedon vertaaminen tuotantotiimin oikeuksiinkuluttamaan aikaan.

Pääsynhallintamenetelmän valinta voi olla yrityksille vaikeaa sen vuoksi, ettäeri menetelmien vaikutukset toteutuksen tehokkuuteen ja tietoturvaan eivät vält-tämättä ole tiedossa etukäteen tai ovat vaikeasti ennustettavia. Jatkotutkimus eripääsynhallintamenetelmien vaikutuksista tehokkuuteen ja tietoturvaan auttaisi yri-tyksiä vertailemaan menetelmiä keskenään paremmin. Lisäksi mahdollisuus käyttääuseampaa menetelmää samanaikaisesti voi tuoda sellaisia etuja, joita ei yhdellä me-netelmällä saavuteta.

63

Viitteet

[1] O�ce of Government Commerce. ITIL Service Operations. United Kingdom,The Stationery O�ce, 2007. ISBN 978-0-11-331046-3.

[2] O�ce of Government Commerce. ITIL Service Design. United Kingdom, TheStationery O�ce, 2007. ISBN 978-0-11-331047-0.

[3] Johansson, M. BS 7799, Tietoturvan Hallinta. Suomi, Helsingin Yliopisto, 2003.

[4] International Organization for Standardization. ISO/IEC 27002:2005 Informa-tion technology � Security techniques � Code of practice for information securitymanagement. Switzerland, 2007-07-01.

[5] International Organization for Standardization. ISO/IEC 27001:2005 Informa-tion technology � Security techniques � Information security management sys-tems � Requirements. Switzerland, 2005-10-15.

[6] White, Gregory B., Fisch, Eric A. ja Pooch, Udo W. Computer System andNetwork Security. CRC Press, 1996. ISBN: 0-8493-7179-1.

[7] Johnston, R., Clark, C. Service Operations Management - Improving ServiceDelivery. Third Edition. Edinburgh Gate Harlow, Pearson Education Limited,2008. ISBN 978-14058-4732-2.

[8] Macfarlane, I., Rudd, C. itSMF The IT Service Management Forum: IT Pal-velunhallinta � ITIL Käsikirja. ISBN 0-9551245-2-2.

[9] International Organization for Standardization. ISO/IEC 20000-1:2005 Infor-mation technology � Service management - Part 1: Speci�cation. Switzerland,2005-12-15.

[10] Benantar, M. Access Control Systems - Security, Identity Management andTrust Models. United States of America, Springer Science+Business Media,Inc., 2006. ISBN 978-0-387-00445-7.

[11] Altmann, J., Sampath, R. UNIQuE: A User-Centric Framework for NetworkIdentity Management. South Korea, Seoul National University.

[12] URI Planning Interest Group. URIs, URLs, and URNs: Clari�cations andRecommendations 1.0. Verkkodokumentti. W3C/IETF. Viitattu 16.8.2011.Saatavissa: http://www.w3.org/TR/uri-clarification/.

[13] XDI.ORG. Infrastructure for accountable networks. Verkkosivu. XDI.ORG -an international non-pro�t public trust organization governing open public XRIand XDI infrastructure. Viitattu 16.8.2011. Saatavissa: http://www.xdi.org/.

64

[14] ISO. Management and leadership standards - Certi�cation. Verkkodokumentti.International Organization for Standardization. Viitattu 29.8.2011. Saatavissa:http://www.iso.org/iso/iso_catalogue/management_and_leadership_

standards/certification.htm.

[15] IsecT Ltd. ISO/IEC 2001 certi�cation standard. Verkkodokument-ti. IsecT infosec consulting. Viitattu 29.8.2011. Saatavissa: http:

//www.iso27001security.com/html/27001.html.

[16] Sandhu, Ravi S., Smarati, Pierangela. Access Control: Principles and Practice.IEEE Communications Magazine, September 1994.

[17] Jäntti, M., Lahtela, A., Kaukola, J. Establishing a Measurement System forIT Service Management Processes: A Case Study. International Journal onAdvances in Systems and Measurements, 2010, vol. 3 no. 3 amd 4.

[18] European Committee for Standardization. DIN EN ISO 9001:2008 Quality ma-nagement systems � Requirements. German, 2008.

[19] Inspecta. Serti�ointi. Verkkosivu. Inspecta Group, 2011. Viitattu 6.9.2011. Saa-tavissa: http://www.inspecta.com/fi/Palvelut/Sertifiointi/.

[20] Lampson, B. W. Protection. ACM Operating System Review, 1974, vol. 8, no.1, s. 18-24.

[21] Bell, D. E. ja LaPadula, L. J. Secure Computer Systems: Mathematical Founda-tions. MITRE Technical Report 2547, 1973, vol. 1. Mitre Corporation, Bedford,MA, 1975.

[22] Ferraiolo, David F., Kuhn, R. Role-Based Access Controls. 15th National Com-puter Security Conference, 1992, s.554 - 563. National Institute of Standardsand Technology, USA, Gaithersburg, U.S. Department of Commerce, Md.20899.

[23] Northcutt, S. Role Based Access Control to Achieve Defense in Depth. Verkko-dokumentti. SANS Technology Institute, 2007. Viitattu 28.9.2011. Saatavissa:http://www.sans.edu/research/security-laboratory/article/311

[24] May�eld, T., Roskos, J. E., Welke, S. R., Boone, J. M. Integrity in Automa-ted Information Systems. C TECHNICAL REPORT 79-91, September 1991,National Computer Security Center (NCSC). Alexandria, Virginia.

[25] Vanamali, S. Role Engineering: The Cornerstone of Role-Based Access Control.White Paper: Role Engineering and Role-Based Access Control. CISA, CISSP.CA Services, July 2008.

[26] Coyne, Edward J. Role Engineering and Why We Need It. Role Engineering forEnterprise Security Management, 2007, Chapter 4. Artech House Publishers.ISBN: 9781607832225.

65

[27] Vaidya, J., Atluri, V., Guo, Q. The Role Mining Problem: Finding a MinimalDescriptive Set of Roles. SACMAT�07, 2007, June 20-22. Sophia Antipolis,France.

[28] Josang, A., Pope, S. User Centric Identity Management. CRC for Enterpri-se Distributed Systems and Technology (DSTC Pty Ltd), The University ofQueensland, 4072, Australia. AusCERT Conference 2005.

[29] Gaedke, M., Meinecke, J., Nussbaumer, M. A Modeling Approach to FederatedIdentity and Access Management. University of Karlsruhe 2005.

[30] Kasanen, Hannu. Keskitetty identiteetinhallinta, Referenssiarkkitehtuuri. Sec-proof, Finland, 09/2010.

[31] Massachusetts Institute of Technology, Secure Endpoints Inc. Network IdentityManager 1.3.1. User Documentation, MIT Kerberos for Windows Release 3.2.2.Massachusetts Institute of Technology 2007.

[32] Microsoft. Active Directory Overview. Verkkodokumentti. Microsoft2011. Viitattu 28.9.2011. Saatavissa: http://www.microsoft.com/en-us/

server-cloud/windows-server/active-directory-overview.aspx.

[33] kansanvalta.�. Koulutus ja kehittäminen. Verkkodokumentti. Kansanvalta.�2011. Viitattu 28.9.2011. Saatavissa: http://www.kansanvalta.fi/Etusivu/Tutkimusjakehitys/Sosiaalisenmedianmahdollisuudethallinnollepa/

Koulutusjakehittaminen.

[34] Atos. Identity and Access Management with DirX. Verkkosi-vu. Atos 2011. Viitattu 29.9.2011. Saatavissa: http://atos.

net/en-us/solutions/identity-security-and-risk-management/

identity-and-access-management-with-dirx/default.htm.

66

A Roolitietojen keräämiseen käytetty kaavake

Team permissions

Template is �lled with example information; please overwrite them with informa-tion relevant to the team.

Org. Unit: FI UNIX

E-mail groups:AD group mem-bership

Target Channel/Contact

Windows Server Team mem-bers

Approval from Superior ande-mail to service desk.

Sharepoint:SharePointAccess Level

Target Channel/Contact

Windows Server Team mem-bers

Lotus Notes Check InRequest SharePointRequest

Remote ser-vers:Server Target Permission Channel/ContactServername Team mem-

bersuser Superior requests through

ARAP

67

OSD:Pro�le Target Channel/ContactProduction Team mem-

bersSuperior �lls: OSD useraccount request form

Clearances:Clearance Target Channel/ContactDC1 Team mem-

bersARAP

Portals:Portal Target Permission Channel/ContactCMWeb Team mem-

bersuser ARAP

Notes:Tool Target Channel/ContactID Team mem-

bersService Desk

CATS:Project Target Channel/Contact

Team mem-bers

Project owner de�nes theorganization units that canbook hours to that project.

68

B Vaatimusmäärittely pääsynhallinnan toteutuseh-

dotukselle

Taulukko 11: Toteutusehdotuksen vaatimusmäärittely

Nro. Nimi Kuvaus Prioriteetti1 Käyttäjäystävällinen

käyttöoikeuspyynnöilletarkoitettu käyttöliitty-mä

Käyttöoikeuspyyntöjen tekemi-nen onnistuu ilman ohjeistusta jaavustusta.

P

2 RBAC mallin käyttö. Ratkaisu tukee RBAC mallia.Rooliperustainen pääsynhallintavähentää yksittäisten pyyntöjenmäärää ja selkeyttää pääsynhal-lintaa.

P

3 Sääntöihin perustuva au-tomaattinen oikeuksienjakaminen.

Ratkaisu mahdollistaa sääntöihinperustuvan oikeuksien automaat-tisen jakamisen.

P

4 Käyttöoikeuskohteidenparannettu ylläpito jahallinta.

Käyttöoikeuskohteet ovat ajantasalla ja niiden ylläpito ja hal-linta on helppoa.

P

5 Automaattinen pyynnönoikeellisuuden tarkistus.

Ratkaisu automaattisesti tarkis-taa pyynnön oikeellisuus; saakohakija hakea oikeuksia, onko pyy-detyt oikeudet jo olemassa, jne.

P

6 Automaattinen hyväksy-jien määrittäminen

Ratkaisun tulee automaattisestimäärittää pyynnölle oikeat hy-väksyjät, noudattaen SoD:ia.

P

7 Käyttöoikeuspyyntöjenprovisioint tiketöintityö-kaluun.

Ratkaisu tukee pyyntöjen lähe-tystä tiketöintityökaluun toteu-tettavaksi tuotantotiimeille.

P

8 Automaattinen käyttö-oikeuskohteiden jaotteluvalittuihin kategorioihin.

Ratkaisu kykenee lajittelemaanpyydetyt oikeudet oikeisiin kate-gorioihin, jotta ne voidaan ohjataoikeaan tuotantotiimiin toteutet-tavaksi tiketöintityökalulla.

T

69

9 Tiketöintityökalunpaluuvies-tien/statustietojentulkitseminen.

Ratkaisu kykenee tulkitsemaantiketöintityökalusta saatuja pa-luuviestejä ja muuttamaan käyt-töoikeuspyynnön toteutuksen ti-laa niiden mukaan.

P

10 Käyttöoikeuspyyntöjenprovisiointi sähköposti-viestinä.

Ratkaisu tukee pyyntöjen lähe-tystä sähköpostiviesteinä toteu-tettavaksi valituille kohteille.

P

11 Käyttöoikeuspyyntöjenprovisiointi suoraankohdejärjestelmiin.

Ratkaisu mahdollistaa oikeuksienprovisiointia suoraan kohdejärjes-telmiin.

T

12 Automaattinen tilatieto-jen ilmoittaminen oikeu-den pyytäjälle ja oikeu-den saajalle.

Ratkaisun kykenee viestimään oi-keuden pyytäjälle ja oikeudensaajalle toteutuneet ja hylätytpyynnöt.

P

13 Omien käyttöoikeuksientarkastelu käyttäjille.

Ratkaisu mahdollistaa käyttäjientarkastella omia käyttöoikeuksi-aan.

T

14 Pääkäyttäjille näkyvyysja muokkausmahdolli-suudet järjestelmiin joitahe hallitsevat.

Ratkaisu mahdollistaa pääkäyttä-jien tarkastella ja muokata hallin-noimiensa järjestelmien käyttöoi-keuksia.

T

15 Kaikkien käyttöoikeus-kohteiden hallinnoimi-nen.

Ratkaisu mahdollistaa kaikkienkäyttöoikeuskohteisiin tehtyjenoikeuspyyntöjen hallinnoimisenriippumatta niiden luonteesta.

A

16 Käyttöoikeuskohteidenja roolien etsiminen.

Ratkaisu mahdollistaa helpon ta-van etsiä haettavia käyttöoikeus-kohteita ja rooleja.

T

17 Usean käyttöoikeuskoh-teen hakeminen kerralla.

Ratkaisu mahdollistaa useankäyttöoikeuskohteen hakemisenkäyttäjälle kerralla.

T

18 Oikeuksien hakeminenjoukolle henkilöitä.

Ratkaisu mahdollistaa oikeuksienhakemisen usealle henkilölle ker-ralla.

A

19 Vanhentuneiden käyttä-jätilien ja käyttöoikeuk-sien automaattinen pois-taminen.

Ratkaisu mahdollistaa automaat-tisen vanhentuneiden käyttäjäti-lien ja käyttöoikeuksien poistami-sen.

P

20 Käyttöoikeuspyyntöjentilatietojen ja jaettu-jen käyttöoikeuksientarkastelu.

Ratkaisu mahdollistaa pyyntöjentilatietojen tarkastelun ja jaettu-jen käyttöoikeuksien listaamisen.

P