TIETOKANTAKÄYTTÄJÄN AUTENTIKOINNIN JA AUKTORISOINNIN HALLINNOINTI ACTIVE DIRECTORY -YMPÄRISTÖSSÄ

LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOTEKNIIKAN OSASTO TIETOKANTAKÄYTTÄJÄN AUTENTIKOINNIN JA AUKTORISOINNIN HALLINNOINTI ACTIVE DIRECTORY -YMPÄRISTÖSSÄ Diplomityön aihe on hyväksytty Tietotekniikan osaston osastoneuvostossa 17.8.2005. Työn tarkastajat: Professori Heikki Kälviäinen DI Toni Häkkänen Työn ohjaaja: DI Toni Häkkänen Lappeenrannassa, 31.1.2006 Ville Kinnunen Tervahaudankatu 1 B 26 53850 Lappeenranta 050-5667477

TIIVISTELMÄ Lappeenrannan teknillinen yliopisto Tietotekniikan osasto Ville Kinnunen Tietokantakäyttäjän autentikoinnin ja auktorisoinnin hallinnointi Active Directory -ympäristössä Diplomityö 2006 94 sivua, 25 kuvaa, 6 taulukkoa ja 2 liitettä Tarkastajat: Professori Heikki Kälviäinen DI Toni Häkkänen Hakusanat: tietokannat, autentikointi, auktorisointi, Active Directory Keywords: databases, authentication, authorization, Active Directory Usean nykypäivän yrityksen tietojärjestelmäinfrastruktuuri on muotoutunut heterogeeniseksi ympäristöksi, jossa eri käyttöjärjestelmä- ja laitealustoilla toimii usean eri valmistajan toimittamia järjestelmiä. Heterogeenisen ympäristön hallitsemiseksi yritykseltä vaaditaan keskitettyä tietovarastoa, johon on tallennettu tietoa käytetystä järjestelmäympäristöstä sekä sen komponenteista. Tähän tarkoitukseen Microsoft toi markkinoille vuonna 1999 Active Directory 2000 -hakemistopalvelun. Heterogeenisessa ympäristössä käyttäjien autentikointi ja auktorisointi on erittäin vaativaa. Pahimmassa tapauksessa käyttäjällä voi olla kymmeniä käyttäjätunnus-salasana-yhdistelmiä yrityksen eri tietojärjestelmiin. Lisäksi jokaisessa tietojärjestelmässä on ylläpidettävä käyttäjäkohtaisia toimintavaltuuksia. Niin käyttäjän kuin ylläpitäjänkin näkökulmasta tällainen skenaario on painajainen. Tässä diplomityössä kartoitetaan mahdollisuuksia Oracle-tietokantojen käyttäjien autentikoinnin sekä auktorisoinnin keskittämiseksi Active Directory -hakemistopalveluun. Työssä tarkastellaan tarkoitukseen soveltuvia valmiita kaupallisia ratkaisuja sekä tutkitaan mahdollisuuksia oman ratkaisumallin toteuttamiseksi ympäristöstä löytyvien ohjelmointirajapintojen avulla. ii

ABSTRACT Lappeenranta University of Technology Department of Information Technology Ville Kinnunen Administration of database user's authentication and authorization in Active Directory environment Master's Thesis 2006 94 pages, 25 figures, 6 tables and 2 appendices Examiners: Professor Heikki Kälviäinen M.Sc. Toni Häkkänen Keywords: databases, authentication, authorization, Active Directory In many of modern-day's enterprises data processing system infrastructure has transformed to a heterogeneous environment where several systems provided by various vendors are running on the top of different operating systems and hardware. To administer this kind of environment enterprise needs a central data warehouse where is stored information about system environment and its components. For this purpose Microsoft launched a directory service called Active Directory 2000 at 1999. Authentication and authorization of users is very testing in heterogeneous environments. At the worst user can retain tens of username-password combinations for various processing systems in the enterprise. In addition to this they have created user-specific tokens for all of the processing systems. As from a user's as from an administrator's point of view this kind of scenario is a nightmare. The goal of this master's thesis is to survey possibilities for centralizing user authentication and authorization of Oracle-database users to Active Directory. In this thesis there will be a review of some existing commercial products and a research of the possibility to develop an own solution using application programming interfaces offered by the environment. iii

ALKUSANAT Nöyrimmät kiitokset diplomityön tarkastajalle, professori Heikki Kälviäiselle, sekä ohjaajalle, DI Toni Häkkäselle, jotka asiantuntemuksellaan viitoittivat työn toteuttamista. Kiitokset myös Kaukaan tietohallintopäällikölle, Timo Rautiaiselle, tämän työn mahdollistamisesta. Kotirintamalta tahdon kiittää avovaimoani, Johannaa, kaikesta siitä työstä, jonka hän on tehnyt perheemme hyväksi. Erityiskiitos pojalleni, Veetille, joka usein kuljetti ajatukseni pois opiskelujen huolista ja murheista. Vanhemmilleni haluan osoittaa suurta kiitosta tuesta ja kannustuksesta opintojeni aikana. iv

SISÄLLYSLUETTELO 1 JOHDANTO... 7 1.1 Työn taustaa... 7 1.2 Tavoitteet ja rajaus... 7 1.3 Työn rakenne... 8 2 AUTENTIKOINTI... 9 2.1 Evoluutio... 9 2.2 Arkkitehtuurit... 10 2.2.1 Jotain mitä käyttäjä tietää... 10 2.2.2 Jotain mitä käyttäjällä on... 11 2.2.3 Jotain mitä käyttäjä on... 12 2.2.4 Hybridi-arkkitehtuurit... 14 2.3 Autentikointimallit... 14 2.3.1 Järjestelmäkohtainen autentikointi... 14 2.3.2 Keskitetty autentikointi... 15 2.3.3 Salasanojen synkronointi... 16 2.3.4 Kertakirjautuminen... 16 2.3.5 Redusoitu kirjautuminen... 17 2.3.6 Digitaaliset sertifikaatit... 17 3 AUKTORISOINTI... 18 3.1 Tarkoitus... 18 3.2 Subjekti ja objekti... 19 3.3 Politiikat ja mekanismit... 19 3.4 Mallit... 20 3.4.1 Harkinnanvarainen pääsynvalvonta... 20 3.4.2 Pakollinen pääsynvalvonta... 21 3.4.3 Roolipohjainen pääsynvalvonta... 22 1

4 TIETOTURVA... 23 4.1 Autentikoinnin uhat... 23 4.2 Auktorisoinnin uhat... 26 4.3 Käyttäjät ja asenteet... 27 4.4 Suojautuminen... 27 5 ACTIVE DIRECTORY -HAKEMISTOPALVELU... 29 5.1 Tietorakenne... 30 5.1.1 Kevennetty hakemistopalveluprotokolla... 32 5.2 Toimialueet, puut ja metsät... 33 5.3 Kirjautuminen ja autentikointi... 35 5.3.1 Windows-tietoturvamalli... 36 5.3.2 Kerberos 5 -protokolla... 38 5.4 Auktorisointi... 44 5.5 Ohjelmointirajapinnat... 47 5.5.1 Active Directory -palvelurajapinnat... 47 5.5.2 Tietoturvapalvelujen rajapinta... 48 6 ORACLEN TIETOKANNAT... 49 6.1 Verkkorajapinta... 49 6.2 Tietoturvan hallinta... 51 6.2.1 Autentikointi... 51 6.2.2 Auktorisointi... 52 6.2.3 Tietoturvan laajennos... 53 6.3 Ohjelmointirajapinnat... 54 6.3.1 Oracle-pyyntörajapinta... 54 6.3.2 Java-tietokantayhteys... 54 7 KAUKAAN INFRASTRUKTUURI... 56 7.1 Tietojärjestelmät... 56 7.2 Käytettyjä autentikointimalleja... 57 7.3 Tavoitteita... 60 2

8 RATKAISUMALLIT... 61 8.1 Oraclen identiteetin hallinta... 61 8.1.1 Toimintaperiaate... 62 8.1.2 Käyttöönotto ja testitulokset... 63 8.2 Windows-natiivi autentikointiadapteri... 65 8.2.1 Toimintaperiaate... 65 8.2.2 Käyttöönotto ja testitulokset... 65 8.3 Microsoftin identiteetin integrointipalvelin... 66 8.3.1 Toimintaperiaate... 66 8.3.2 Käyttöönotto ja testitulokset... 67 8.4 Omat ratkaisut... 68 8.4.1 Autentikointimenetelmä 1... 68 8.4.2 Autentikointimenetelmä 2... 71 8.4.3 Auktorisointimenetelmä... 72 9 JOHTOPÄÄTÖKSET... 74 10 YHTEENVETO... 78 LÄHTEET... 80 LIITTEET 3

SYMBOLI- JA LYHENNELUETTELO ACE Access Control Entry ACL Access Control List AD Active Directory ADSI Active Directory Service Interfaces AES Advanced Encryption Standard ASO (Oracle) Advanced Security Option CCITT International Telegraph and Telephone Consultative Committee CERT-FI Computer Emergency Response Team FICORA CN Common Name COM Component Object Model DACL Discretionary Access Control List DCE Distributed Computing Environment DCOM Distributed Component Object Model DES Data Encryption Standard FTP File Transmission Protocol GUID Globally Unique Identifier DAC Discretionary Access Control DAP Directory Access Protocol DIT Directory Information Tree DN Distinguished Name DNS Domain Name System HP-UX Hewlett-Packardin toteutus UNIX-käyttöjärjestelmästä IP Internet Protocol ISO International Organization for Standardization JDBC Java Database Connectivity MAC Mandatory Access Control MD5 Message-Digest version 5 NOS Network Operating System NTML Windows NT LAN Manager KDC Key Distribution Centre 4

LDAP LSA LPC MIIS MIT OCI OIM OSI OU PKC PKI QoS RADIUS RBAC RPC RSA RSO SACL SAM SAS SCP SHA SID SOX SQL SSO SSPI TCP TGS TGT UDP VAX/VMS Lightweight Directory Access Protocol Local Security Authority Local Procedure Call Microsoft Identity Integration Server Massachusetts Institute of Technology Oracle Call Interface Oracle Identity Management Open System Interconnection Organizational Unit Public Key Cryptography Public Key Infrastructure Quality of Service Remote Authentication Dial-In User Service Role-Based Access Control Remote Procedure Call Rivest-Shamir-Adleman Reduced Sign-On System Access Control List Security Accounts Manager Secure Attention Sequence Secure Copy Secure Hash Algorithm Security Identifier Sarbanes-Oxley Structured Query Language Single-Sign-On Security Support Provider Interface Transmission Control Protocol Ticket Granting Server Ticket Granting Ticket User Datagram Protocol Virtual Address extension/virtual Memory System 5

WIS Workstation Infrastructure Service 6

1 JOHDANTO Tämä diplomityö tehtiin Lappeenrannan teknillisen yliopiston Tietotekniikan osastolle. Työn suorituspaikkana toimi UPM-Kymmene Oyj:n Kaukaan yksikön tietohallinto Lappeenrannassa. Ajatus diplomityön suorittamisesta sekä sen aiheesta kehittyi kevään 2005 aikana. Täysipainoinen diplomityön tekeminen aloitettiin elokuussa 2005 ja päätökseensä se saatettiin vuoden 2006 tammikuussa. 1.1 Työn taustaa Kaukaalla on 11 Oracle-tietokantoja käyttävää tietojärjestelmää, joiden yhteenlaskettu käyttäjämäärä on 400-500 henkilöä. Näin suuren tietokantakäyttäjien joukon hallinnointi Kaukaan kaltaisessa heterogeenisessä ympäristössä on vaikeaa ja työlästä. UPM-Kymmene Oyj:n listautuminen New Yorkin pörssiin vuonna 1999 pakotti yhtiön kaikkien yksiköiden noudattamaan SOX-lainsäädäntöä. Kyseisen lainsäädännön tarkoituksena on taata UPM-Kymmene Oyj:n julkaisemien tietojen oikeellisuus ja luotettavuus. Lain vaatimukset koskevat osaltaan myös tietokantakäyttäjien hallinnoinnin rutiineja, käytäntöjä sekä valvontamenettelyjä. Edellä mainittuihin perusteisiin pohjautuen Kaukaan tietohallinto katsoi tarpeelliseksi tutkia mahdollisuuksia tietokantakäyttäjiensä autentikoinnin ja auktorisoinnin kehittämiseksi. 1.2 Tavoitteet ja rajaus Diplomityön tavoitteena on kartoittaa mahdollisuuksia Oracle-tietokantojen käyttäjien autentikoinnin ja auktorisoinnin keskittämiseksi Active Directory -hakemistopalveluun. Keskittämisellä tarkoitetaan, että tietokantakohtaisten käyttäjätunnusten sijaan voitaisiin käyttää toimialueen globaaleja Active Directory -käyttäjätunnuksia. Tällöin vastuu tietokantakäyttäjän autentikoinnista sekä auktorisoinnista olisi yksittäisen tietokannan sijaan Active Directory -hakemistopalvelulla. Keskittämisen lisäksi työssä tutkitaan mahdollisuuksia implementoida tietokantakäyttäjille niin kutsuttua Single-Sign-On -kirjautumismallia. Kyseinen kirjautumismalli mahdollistaisi toimialueelle syötettyjen kirjautumistietojen hyödyntämisen eri tietojärjestelmiin kirjauduttaessa. 7

Työssä tarkastellaan tarkoitukseen soveltuvia valmiita kaupallisia tuotteita sekä tutkitaan mahdollisuuksia oman ratkaisumallin toteuttamiseksi ympäristöstä löytyvien ohjelmointirajapintojen avulla. Kaupallisia tuotteita tutkitaan vaatimusten, kustannusten sekä toteutuksen vaativuuden näkökulmista. Oman ratkaisumallin osalta tarkastellaan, voidaanko ympäristöön toteuttaa vaatimukset täyttävä oma järjestelmä vai löytyykö sen toteuttamiselle esteitä. Diplomityössä keskitytään ainoastaan Oracle-tietokantakäyttäjien autentikointiin ja auktorisointiin, sillä kaikki Kaukaan tuotantokäytössä olevat tietojärjestelmät käyttävät nimenomaan Oraclen tietokantoja. 1.3 Työn rakenne Työ rakentuu siten, että kappaleessa 2 käsitellään autentikointia lähtien liikkeelle perusteista. Kappale esittelee eri autentikointiarkkitehtuurit sekä mallit, joiden pohjalta autentikointiympäristöt muodostuvat. Kappale 3 puolestaan esittelee auktorisoinnin tarkoituksen ja sen keskeiset osa-alueet. Kappale 4 tutkii autentikointiin ja auktorisointiin liittyviä tietoturvauhkia ja niiltä suojautumista. Viides kappale käsittelee Active Directory -hakemistopalvelun toimintaa, rakennetta sekä esittelee sen tärkeimmät autentikointiin ja auktorisointiin liittyvät komponentit. Kappaleessa 6 esitellään Oraclen tietokannat. Kappale tutkii Oracle-tietokantojen yleistä arkkitehtuuria ja toimintaa sekä käsittelee tietokantojen tietoturvaominaisuuksia. Kappaleessa 7 pureudutaan Kaukaan järjestelmäinfrastruktuuriin, sen komponentteihin ja niiden toimintaan sekä selvitetään tietokantakäyttäjien nykytilaa. Kappale 8 esittelee ja vertailee löydettyjä kaupallisia tuotteita sekä tutkii ympäristöstä löytyviä ohjelmointirajapintoja ja niiden potentiaalia oman ratkaisun toteuttamiseksi. Diplomityön yhdeksännessä kappaleessa esitellään saavutettujen tuloksien pohjalta vedetyt johtopäätökset. Kappale visioi myös tulevaisuudessa huomioitavia seikkoja sekä määrittelee UPM-Kymmene Oyj:lle eräitä suosituksia tietokantakäyttäjien autentikointiin ja auktorisointiin liittyen. Diplomityön viimeinen kappale kokoaa yhteenvedon työn tuloksista ja johtopäätöksistä. 8

2 AUTENTIKOINTI Sana autentikointi tulee englanninkielen sanasta authentication, joka vapaasti suomennettuna tarkoittaa oikeaksi todistamista. Tietojärjestelmissä autentikointi on prosessi, jonka avulla käyttäjä todistaa henkilöllisyytensä järjestelmälle. Autentikointi koostuu kahdesta vaiheesta: ensimmäisessä vaiheessa henkilö väittää olevansa henkilö X ja toisessa vaiheessa varmistetaan, että henkilö todella on väittämänsä henkilö X [McD02]. Autentikointia ei pidä sekoittaa tunnistamiseen, jolla tarkoitetaan käyttäjän henkilöllisyyden selvittämistä, ei väitetyn henkilöllisyyden varmentamista. Autentikoinnin toteuttamiseksi löytyy kolme pääarkkitehtuuria, joihin tämän päivän autentikointijärjestelmät pohjautuvat. 2.1 Evoluutio Ihmiset ovat käyttäneet jo vuosisatojen ajan puhuttuja salasanoja todistaakseen henkilöllisyytensä. Muinaiset egyptiläiset hyödynsivät ensimmäisinä mekaanisilla laitteilla suoritettavaa niin kutsuttua miehittämätöntä autentikointia. He käyttivät avaimella toimivaa lukkoa, jolloin autentikointi voitiin suorittaa ilman ihmisen väliin tuloa. Miehittämätön autentikointi on tämän päivän tietokonepohjaisten järjestelmien perusta. [Smi02] Ajatus salasanalla kontrolloidusta miehittämättömästä autentikointijärjestelmästä juontaa juurensa vuosisatojen takaisesta kansantarinasta Ali Baba ja neljäkymmentä rosvoa. Ali Baba rosvoineen säilytti valtaisaa aarretta luolassa, jonka oviaukko oli suojattu suurella kivellä. Salasanalla "Seesam aukene" luolan oviaukkoa suojaava kivi siirtyi. Luolassa oli taianomainen laite, joka reagoi puhuttuun kieleen. Tämä taianomainen laite muistuttaakin paljolti tämän päivän modernia salasanasuojattua työasemaa: molemmat päästävät sisään oikealla salasanalla, mutta eivät kykene tunnistamaan, kuka salasanan käyttäjä oikeasti on. [Smi02] 9

2.2 Arkkitehtuurit Autentikointiarkkitehtuurit jaotellaan kolmeen pääryhmään: "Jotain mitä käyttäjä tietää", "Jotain mitä käyttäjällä on" ja "Jotain mitä käyttäjä on" [Efo03]. Toimintaperiaatteen lisäksi arkkitehtuurit eroavat toisistaan tietoturvan, implementoinnin kustannusten sekä käytettävyyden osalta. Valittaessa järjestelmään soveltuvaa autentikointiarkkitehtuuria on hyvä tuntea arkkitehtuurien välisiä eroja. 2.2.1 Jotain mitä käyttäjä tietää "Jotain mitä käyttäjä tietää" -arkkitehtuuri perustuu konseptiin, jossa käyttäjä sekä autentikoinnin suorittava taho jakavat jonkin salaisuuden keskenään. Arkkitehtuuria hyödyntävät protokollat eroavat toisistaan lähinnä tavassa, jolla ne jakavat yhteisen salaisuuden. Kaikista olemassa olevista autentikointimenetelmistä käytetyin ja tunnetuin on kyseiseen arkkitehtuuriin perustuva käyttäjätunnus-salasana-menetelmä [Pet02]. Menetelmä on yksinkertainen ja se on esitetty kuvassa 1. Käyttäjä syöttää käyttäjätunnuksen ja salasanan autentikointia suorittavalle palvelimelle, joka vertaa käyttäjän syöttämää salasanaa palvelimen muistiin tallennettuun käyttäjäkohtaiseen salasanaan. Salasanojen ollessa yhtäläiset palvelin päästää käyttäjän järjestelmään. [Efo03] Vahvistus [3] Salasana [2] [1] Salasana Kuva 1. Käyttäjätunnus-salasana-menetelmä. [And03] 10

2.2.2 Jotain mitä käyttäjällä on "Jotain mitä käyttäjällä on" -arkkitehtuurissa käyttäjällä on hallussaan jotain, mitä muilla ei ole. Tyypillisesti se on digitaalinen sertifikaatti, laite tai kortti, joka sisältää käyttäjän tunnisteen. Autentikoinnin osapuolien tietämän salaisuuden sijaan arkkitehtuurin turvallisuus perustuu matemaattisiin todennäköisyyksiin. Digitaalisia sertifikaatteja ja tunnistekortteja hyödynnetään niin sanotulla julkisen avaimen infrastruktuurilla (Public Key Infrastructure, PKI). Sertifikaatin tai kortin sisältämää tunnistetta on vaikea selvittää, sillä arkkitehtuuri on hyvin monimutkainen. [Efo03] Julkisen avaimen salaustekniikassa (Public Key Cryptography, PKC) käytetään avainpareja. Käyttäjä generoi itselleen kaksi avainta: julkisen ja salaisen. Salainen avain generoidaan satunnaisluvun avulla esimerkiksi käyttäjän antamasta merkkijonosta. Tämän jälkeen salaisesta avaimesta generoidaan julkinen avain käyttämällä erityistä yksisuuntaista matemaattista funktiota. Funktion yksisuuntaisuuden ansiosta salaisen avaimen takaisingenerointi julkista avainta käyttäen vaatii nykypäivän tietokoneilta vuosien laskenta-ajan. Julkinen avain voidaan siis huoletta julkistaa. Kyseessä on epäsymmetrinen salausmenetelmä, jossa toista avainta käytetään salaamiseen ja toista avainta salauksen purkamiseen. Salaukseen voi käyttää kumpaa tahansa avaimista, mutta purkaminen tapahtuu päinvastaisella avaimella, ei siis samalla avaimella, jolla salaus tehtiin. [Smi02] Kuva 2 esittää, kuinka PKI-pohjainen järjestelmä toimii. Oletetaan, että Aarne haluaa lähettää Bertalle viestin siten, ettei kukaan ulkopuolinen kykene lukemaan tai muokkaamaan lähetettyä viestiä. Bertta haluaa varmistua, että viestin lähettäjä on nimenomaan Aarne. Vaiheessa 1 Aarne kirjoittaa viestin, jonka hän salaa Bertan julkisella avaimella vaiheessa 2. Kolmannessa vaiheessa Aarne allekirjoittaa viestin omalla salaisella avaimellaan ja lähettää viestin Bertalle (vaihe 4.). Viidennessä vaiheessa Bertta purkaa Aarnen lähettämästä viestistä allekirjoituksen käyttämällä Aarnen julkista avainta. Nyt Bertta on varma, että viestin lähettäjä on Aarne. Viesti on vielä salattu ja Bertta purkaakin sen omalla salaisella avaimellaan vaiheessa 6. [Efo03] 11

Kuva 2. Julkisen avaimen infrastruktuuri eli PKI. Laitetasolla PKI-järjestelmän toteutuksen yleisin muoto on niin kutsuttu älykortti (engl. smart card), eli luottokortin kokoinen laite, joka pitää sisällään käyttäjän avainparin. Älykortti vaati järjestelmään liitettävän lukulaitteen, jonka avulla kortin sisältämää avainparia voidaan käyttää. Ohjelmistotasolla yleisin toteutus on digitaalinen sertifikaatti eli ohjelmallinen tunniste, joka sisältää käyttäjän identifioivaa informaatiota. Digitaalisen sertifikaatin allekirjoittaa luotettava kolmannen osapuolen taho omalla salaisella avaimellaan. Tällöin esitetyn digitaalisen sertifikaatin sisällön oikeellisuus voidaan varmistaa käyttämällä sertifikaatin allekirjoittaneen kolmannen tahon julkista avainta. [Efo03] 2.2.3 Jotain mitä käyttäjä on Aiemmin esitetyt arkkitehtuurit perustuivat käyttäjän tietämään salaisuuteen tai käyttäjän hallussa pitämään tunnisteeseen. Jotain mitä käyttäjä on -arkkitehtuuri perustuu johonkin, mitä käyttäjä inhimillisessä mielessä on. Arkkitehtuuri tunnetaan yleisemmin biometrisena autentikointina. Arkkitehtuurissa käyttäjän on esitettävä jotain omasta ihmisyydestään autentikoituakseen [Efo03]. Biometrisen autentikoinnin menetelmät jaetaan kahteen ryhmään: fysiologisiin ja käyttäytymiseen perustuviin. [Fur00] 12

Fysiologinen biometria perustuu ihmisen fyysisiin ominaisuuksiin kuten sormenjälkiin, silmän verkkokalvoon tai iirikseen. Näiden ominaisuuksien tutkiminen vaatii autentikointijärjestelmään liitettävän lisälaitteen, jonka avulla nämä ominaisuudet voidaan muuntaa järjestelmän ymmärtämään formaattiin. Käyttäytymiseen perustuva biometria käsittää puolestaan ominaisuuksia kuten kirjoitustyyli (tietokoneella), ääni tai allekirjoitustyyli. Taulukossa 1 on esitelty yleisimpiä biometriikan menetelmiä. Biometriikan pääasiallinen käyttökohde on käyttäjien tunnistamisessa, ei niinkään autentikoinnissa. [Fur00] Taulukko 1. Yleisimmät biometriset autentikointimenetelmät. [Bio05], [Fur00] MENETELMÄ Näppäin painalluksien analysointi Kasvojen tunnistus Hiiren liikkeet Äänen tunnistus Allekirjoituksen analysointi Iiriksen kuvaus Käden geometria Sormenjälkien analysointi Verisuonet KUVAUS Tutkimusten mukaan käyttäjillä on erilaisia tyylejä painella näppäimistön nappeja. Käyttäjä voidaan autentikoida mittaamalla näppäinpainallusten välisiä aikoja. Käyttäjän kasvoista otettua kuvaa verrataan aiemmin otettuun kuvaan. Käyttäjä voidaan autentikoida tavasta, jolla hän käyttää hiirtä. Käyttäjän lausumaa sanaa verrataan aiemmin nauhoitettuun lausahdukseen. Käyttäjä allekirjoittaa nimensä erityisellä kynällä alustalle, joka lukee kirjoituksen ja järjestelmä vertaa sitä aiemmin talletettuun allekirjoitukseen. Kuvataan käyttäjän iiris siihen tarkoitetulla kameralla ja verrataan kuvaa aiemmin otettuun kuvaan. Mitataan käden fyysisiä mittoja erikoiskameralla ja verrataan niitä aiemmin talletettuihin arvoihin. Kuvataan käyttäjän sormenjälki ja verrataan sitä aiemmin otettuun. Skannaustekniikkalla analysoidaan kämmenen verisuonien välisiä etäisyyksiä ja niiden tuottamaa lämpösäteilyä. 13

2.2.4 Hybridi-arkkitehtuurit Yhdistämällä eri arkkitehtuureja muodostuu niin kutsuttu hybridi-arkkitehtuuri, joka yhdistää käytettyjen arkkitehtuurien vahvuudet ja samalla pienentää käytettyjen arkkitehtuurien riskejä [Efo03]. Yksi käytetyimmistä hybridi-menetelmistä on niin kutsutun RSA-tunnisteen (Rivest-Shamir-Adleman) ja salasanan kombinaatio [Sig01]. Menetelmässä käyttäjällä on laite, joka generoi tietyin väliajoin satunnaisen luvun käyttäen ainutlaatuista symmetristä avainta. Kirjautuessaan käyttäjä syöttää järjestelmään laitteen generoiman luvun sekä oman henkilökohtaisen salasanansa. Autentikoinnin suorittava palvelin on jatkuvasti tietoinen siitä, mikä luku on validi kullekin käyttäjälle. Autentikoinnissa varmennetaan laitteen generoiman luvun ja käyttäjän syöttämän salasanan kombinaation oikeellisuus. [Rsa05] 2.3 Autentikointimallit Heterogeenisessa tietojärjestelmäympäristössä käyttäjällä on usein hallussaan monia järjestelmäkohtaisia kirjautumistietoja. Useimmiten kirjautumistiedoilla tarkoitetaan käyttäjätunnus-salasana-yhdistelmää, sillä ainakin toistaiseksi se on suosituin autentikointimenetelmä. Autentikointimallien avulla kuvataan rakenne, jonka mukaisesti eri autentikointimekanismit implementoidaan heterogeenisiin ympäristöihin. 2.3.1 Järjestelmäkohtainen autentikointi Yksinkertaisimmillaan autentikointimalli toteutetaan siten, että jokaisella järjestelmällä on oma järjestelmäkohtainen autentikointimekanismi. Käyttäjä syöttää jokaiselle järjestelmälle oman käyttäjätunnus-salasana-yhdistelmänsä. Tässä mallissa käyttäjän on muistettava usean eri järjestelmän käyttäjätunnus-salasana-yhdistelmä. Ylläpitäjän näkökulmasta malli on erittäin työläs ja vaikeasti hallittava, koska jokaista käyttäjää on kontrolloitava järjestelmäkohtaisesti. Mallin hyvänä puolena voidaan pitää sitä, että yhden järjestelmän salasanan joutuessa vääriin käsiin ovat muut järjestelmät turvassa. Tämä tietenkin edellyttää, että käyttäjä on valinnut erilaiset salasanat jokaiseen järjestelmään. [And03] 14

2.3.2 Keskitetty autentikointi Keskitetyssä autentikointimallissa järjestelmät käyttävät yhteistä autentikoinnin suorittavaa palvelinta kuten kuvassa 3 on esitetty. Yleensä kaikki kuvassa 3 näkyvät kommunikointikanavat ovat salattuja. Mallin huonona puolena on kuviteltu tilanne, jossa käyttäjän salasana joutuu vääriin käsiin. Tällöin yhden järjestelmän sijaan kaikki järjestelmät ovat vaarassa. Lisäksi käyttäjän on edelleen syötettävä kirjautumistietonsa jokaiselle järjestelmälle. Verrattuna edelliseen malliin, on keskitetty autentikointi käyttäjän kannalta helpompi. Mallissa käyttäjällä on muistettavaan vain yksi käyttäjätunnus-salasana-yhdistelmä usean sijasta. Myös ylläpitäjän on helpompi hallita käyttäjätunnuksia keskitetyltä palvelimelta. [And03] Kuva 3. Keskitetty autentikointimalli. [And03] 15

2.3.3 Salasanojen synkronointi Edellä esitettyjen mallien variaationa voidaan toteuttaa malli, jossa järjestelmien salasanat synkronoidaan. Synkronoinnin toteuttamiseen on kaksi lähestymistapaa [And03]: 1. Käyttäjä vaihtaa salasanansa erillisellä sovelluksella, joka vaihtaa samanaikaisesti salasanan kaikkiin linkitettyihin palveluihin. 2. Salasana vaihdetaan yhdessä palvelussa, josta se siirretään muihin palveluihin. Salasanojen synkronointiin ei ole olemassa kunnollisia standardeja, jolloin synkronoinnin implementaatiot perustuvat eritasoisiin "kotitekoisiin" tekniikoihin. Lisäksi järjestelmiä on vaikea hallinnoida, jos ne joutuvat syystä tai toisesta epäsynkroniseen tilaan. Salasanojen synkronoinnin hyvänä puolena voitaneen pitää sen yksinkertaisimmillaan helppoa toteutusta. [And03] 2.3.4 Kertakirjautuminen Kertakirjautumisessa (Single-Sign-On, SSO) käyttäjä syöttää kirjautumistietonsa vain aloittaessaan istunnon työasemallaan. Kirjauduttuaan toimialueelle käyttäjän ei tarvitse enää syöttää kirjautumistietojaan järjestelmille, vaan käyttäjä pystyy käyttämään kaikkia resursseja, joihin hänellä on oikeus. Tällöin järjestelmäkohtainen autentikointi tapahtuu käyttäjän huomaamatta hyödyntäen Kerberos-protokollaa, joka on tällä hetkellä varteenotettavin mahdollisuus kertakirjautumisympäristöjen toteuttamiseen. [And03], [Gar03] Kerberos-pohjaisen autentikointimallin vahvuutena on todellinen kertakirjautumisympäristö. Kerberos on myös erittäin turvallinen ratkaisu, koska siinä ei liikutella salasanoja ja sen avulla on mahdollista delegoida autentikointi toiselle palvelimelle. Huonona puolena mainittakoon tarve erityisille sovelluksille, jotka mahdollistavat Kerberos-tuen. Usein näitä tarvittavia sovelluksia ei ole saatavilla. [And03], [Gar03]. Kerberosta käsitellään tarkemmin kappaleessa 5.3.2. 16

2.3.5 Redusoitu kirjautuminen Kertakirjautumisen implementointi on useissa ympäristöissä lähestulkoon mahdotonta. Tällöin voidaan kuitenkin hyödyntää niin sanottua redusoitua kirjautumista (Reduced Sign-On, RSO), joka toimii kertakirjautumisen tavoin. Redusoidussa kirjautumisessa kertakirjautuminen ei kosketa kaikkia infrastruktuurin järjestelmiä. Käyttäjän kirjauduttua työasemalleen ei hänen tarvitse syöttää kirjautumistietojaan uudelleen jokaiselle järjestelmälle. Kuitenkin tietyt järjestelmät vaativat erillisen kirjautumistietojen syöttämisen. Redusoidussa autentikointimallissa voidaan hyödyntää edellä mainittua Kerberos-protokollaa. Tällöin ympäristön Kerberos-protokollaa käyttävät järjestelmät ovat niin sanotusti kerberisoituja. [Gar03], [Fle98] 2.3.6 Digitaaliset sertifikaatit X.509-standardissa [Hou02] määriteltyjen digitaalisten sertifikaattien avulla voidaan helposti toteuttaa muun muassa Web-pohjaisten sovellusten käyttäjien autentikointi. Käyttäjälle myönnetään digitaalinen sertifikaatti, jonka aitouden palvelin varmistaa. Palvelimelle myönnetään myös oma sertifikaatti, jonka perusteella käyttäjä voi todentaa palvelimen aitouden. Molemmat sertifikaatit on allekirjoitettu luotettavan kolmannen osapuolen toimesta, jolloin niin käyttäjä kuin palvelinkin voivat olla varmoja siitä, että vastapuoli todella on se joka väittää olevansa. Sertifikaattien ylläpidossa ja luotettavuuden takaamisessa on kuitenkin vielä ongelmia, jotka vaikuttavat niiden käytettävyyteen. [And03]. Digitaalisten sertifikaattien toiminta perustuu julkisen avaimen infrastruktuuriin, jota käsiteltiin tarkemmin kappaleessa 2.2.2. 17

3 AUKTORISOINTI Autentikointi ei ota kantaa siihen, mitä käyttäjä saa ja mitä ei saa tehdä järjestelmän sisällä. Siksi tarvitaankin auktorisointia (engl. authorization), jolla tarkoitetaan käyttäjän oikeuksien hallinnointia [Hay00]. Auktorisoinnin yhteydessä esiintyy myös termi pääsynvalvonta (engl. access control). Lähteestä riippuen kyseisiä termejä pidetään joko yhtäläisinä tai ne erotellaan siten, että auktorisoinnilla kuvataan korkeammalla tasolla tapahtuvaa käyttäjän oikeuksien hallinnointia ja pääsynvalvonnalla tarkoitetaan yksittäistä menetelmää tai mallia oikeuksien kontrolloimiseksi. 3.1 Tarkoitus Auktorisoinnissa kontrolloidaan subjektin ja objektin vuorovaikutusta eritasoisten politiikkojen määrittelemien mekanismien avulla. Auktorisoinnissa mekanismi ja politiikka sidotaan yhteen käytetyn mallin määrittämällä tavalla. Auktorisointijärjestelmän tavoitteena on suojata järjestelmän resursseja asiattomalta ja ei toivotulta käytöltä. Auktorisointi voi tapahtua järjestelmän infrastruktuurin eri alueilla ja tasoilla. Kun käyttöjärjestelmä suojaa auktorisoinnilla tiedostoja ja hakemistoja, suojaa tietokanta tauluja ja näkymiä. [Fer03] Liiketoiminnan näkökulmasta auktorisointijärjestelmän tavoitteena on tarjota optimaalinen tiedonjakaminen järjestelmän käyttäjien kesken. Käyttäjien toimintavaltuuksia on pystyttävä hallitsemaan siten, ettei käyttäjän ulottuville päädy tälle kuulumatonta informaatiota, mutta samalla on pystyttävä takaamaan, että käyttäjällä on esteetön pääsy työn kannalta tarpeellisiin resursseihin. Auktorisoinnilla on suoria vaikutuksia tuottavuuteen: hyvin hoidettu ja tehokas auktorisointijärjestelmä tukee tiedon jakamista, kun tehoton ja huonosti hoidettu auktorisointijärjestelmä vaikeuttaa sitä. [Fer03] 18

3.2 Subjekti ja objekti Auktorisoinnissa subjektilla tarkoitetaan tietokonepohjaista oliota, joka voi luoda objektiin kohdistuvia pyyntöjä. Subjekti voi olla muun muassa käyttäjä tai prosessi. Objekti on puolestaan järjestelmän olio, jota kohtaan voidaan suorittaa pyyntöjä. Objekti voi olla esimerkiksi käyttöjärjestelmän tiedosto tai tietokannassa objekti voi esittää taulua tai näkymää. Pääsy objektiin tarkoitta yleensä pääsyä objektin sisältämään informaatioon, mutta se voi liittyä myös käytettävän järjestelmän resurssiin, kuten laitteeseen. Muita esimerkkejä mahdollisista objekteista ovat puskurit, rekisterit, muistialueet, hakemistot, ohjelmat, prosessorit sekä tulostimet. [Fer03] 3.3 Politiikat ja mekanismit Auktorisointijärjestelmän politiikat (engl. policies) ovat korkeantason vaatimuksia, jotka määräävät, kuinka pääsyä resursseihin kontrolloidaan. Politiikat määräävät, kenellä on oikeus ja missä olosuhteissa ja mihinkä resurssiin. Politiikka voi olla sovelluskohtainen tai se voi koskea käyttäjää organisaation yksikön sisäisessä järjestelmässä. Politiikka voi myös seurata käyttäjää ulkoisiin järjestelmiin saakka. Politiikan luonne on dynaaminen ja sillä on tapana muuttua ajan kuluessa. Tämä johtuu useimmiten organisaation sisäisistä käyttäjän työnkuvaa koskevista muutoksista. [Fer03] Auktorisoinnin politiikat toteutetaan mekanismeilla, jotka tulkitsevat resursseihin kohdistuvia pyyntöjä salliakseen tai kieltääkseen pääsyn kyseiseen resurssiin. Auktorisoinnin mekanismi vaatii, että resursseista (objekteista) ja käyttäjistä (subjekteista) talletetaan tarvittavat attribuutit. Käyttäjäkohtaiset attribuutit sisältävät tietoa käyttäjän tunnisteista, ryhmistä, rooleista tai käyttäjälle myönnetystä luottamustasosta. Resurssien attribuutit voivat puolestaan sisältää esimerkiksi tietoa resurssin luottamustasosta, tyypistä tai niin sanotun pääsynvalvontalistan (Access Control List, ACL). [Fer03] 19