Laajasti ottaen pääsynvalvonnan tehtävänä on autentikoinnin jälkeen tarkastaa, mihin käyttäjällä on oikeudet, ja pitää huoli, että hän pysyy niiden rajoissa ja on vastuussa resurssien käytöstä. Nämä kolme yhteen nivoutuvaa toimintaa ovat erityisesti tietoverkoissa saaneet lyhenteen AAA, sanoista authentication, authorisation ja accounting, jotka ovat tämän pääluvun otsikkona. Luonnollisesti vastuuta käsitellään turvallisuuden eikä laskutuksen tai toimintakertomusten näkökulmasta.
Tämä pääluku alkaa “keskimmäisestä A”:sta eli valtuutuksesta, joka tämän tekstin yhteydessä tarkoittaa kuitenkin jotain, joka tapahtuu jo ennen autentikointia. Authorisation voi eri yhteyksissä tarkoittaa joko oikeuksien asettamista (kauankin) ennen autentikointia tai niiden tarkistamista (piankin) autentikoinnin jälkeen. Muutkin A:t ovat termeinä sikäli yliladattuja, että eri lähteistä löytyy erilaisia painotuksia. Tämä kannattaa muistaa, kun opiskelet tätä tekstiä, jossa asia esitetään yhdellä tavalla.
Valtuutus¶
Pääsynvalvonta (access control) perustuu valtuutukseen (authorisation) ja autentikointiin (authentication). Valtuutus puolestaan perustuu (tietoturva)politiikkaan, eli siihen, millaista turvallisuutta halutaan — kenelle pääsy halutaan myöntää mihinkin. Palataan politiikkaan hieman tuonnempana ja määritellään ensin valtuutus ja pääsynvalvonta. Suomen kielessä valtuutuksesta käytetään joskus termiä auktorisointi ja autentikoinnista termejä todennus tai todentaminen.
Valtuutus tai auktorisointi (authorisation)
Henkilölle tai järjestelmälle tiettyyn tarkoitukseen myönnetty oikeus. Valtuutuksen avulla voidaan esim. myöntää vain tietyille henkilöille pääsy tietojärjestelmän tiettyihin osiin. Tietojärjestelmä voi tarkistaa valtuutuksen käyttäjätunnuksen avulla. Valtuutus tarkistetaan yleensä autentikoinnin jälkeen.
Tässä luvussa esiintyvät käsitteiden määritelmät pohjaavat Tepa-termipankkiin.
Pääsynvalvonta¶
Jos sopivasti ajattelee, lähes kaikkea tietoturvaa voisi luonnehtia siten, että oikeat ja vain oikeat henkilöt pääsevät oikeissa aikeissa käsiksi johonkin tietoresurssiin. Toisaalta tämä ilmaisee vain sen, mistä pääsynvalvonnassa on kyse. Pääsynvalvonta koskee tiivistetysti sitä, miten henkilön, toiminnan ja kohteen muodostama kolmikko voidaan ratkaista oikeaksi tai vääräksi. Pääsynvalvonta ei luonnossa koskaan esiinny näin pelkistettynä. Sen edelle tarvitaan yleensä autentikointia ja pääsypäätöksen jälkeen pitää olla jokin erotteleva mekanismi, jolla hyväksytyille voidaan pääsy toteuttaa ja hylätyiltä se estää. Koko jutun edellä täytyy olla jokin prosessi, jossa säädetään millaiset pääsyt ovat oikeita ja millaiset eivät. Siihen liittyy sellainenkin “pikkuseikka”, että henkilöt ja muut oliot on nimettävä, jotta järjestelmä voisi tehdä mitään eroa niiden välille (eli tunnistaa ne). Tämä kokonaisuus kattaakin tietoturvasta varsin suuren osan.
Pääsynvalvonta (access control)
Menettelyt, joilla pyritään rajaamaan pääsy tietojärjestelmään tai tietoihin vain valtuutetuille tahoille.
Pääsynvalvonta on prosessi, jonka aikana joko myönnetään tai evätään pääsy. Prosessi tarvitsee seuraavat syötteet:
- Kuka teki pyynnön?
- Mitä pyydetään?
- Mitä sääntöjä sovelletaan, kun pyyntöä käsitellään?
Ensimmäisen kohdan “kuka” voi olla ihminen, laite, tietyllä tavalla konfiguroitu laite, järjestelmä tai ohjelma, esim. mobiilisovellus. Teknisesti laitteessa esitettävät pääsypyynnöt esittää jokin prosessi, eikä esim. käyttäjä suoraan. Tämän vuoksi ensimmäinen kysymys on oikeastaan: “kenen tai minkä pyynnöstä prosessi esittää pääsypyynnön?”
“Mitä pyydetään” on usein yhdistelmä suoritettavasta toiminnasta ja kohteesta, jolle toimenpide suoritetaan.
Säännöt ovat loogisia lausekkeita, jotka vaikuttavat päätökseen. Perustapauksessa päätös on salli (permit) tai kiellä (deny). Säännöt muodostavien politiikkojen tarkentuessa voi olla syitä lisätä määrittelemätön (indeterminate) päätös. Päätös voi myös määrätä suoritettaviksi lisätoimenpiteitä, joita joskus kutsutaan velvoitteiksi (obligations), esim. tee lokimerkintä.
Ydinkäsitteet¶
Termiä ((tieto)turva)politiikka (security policy) käytetään sekä organisaation yleisistä säännöistä, jotka määräävät, kuinka arkaluonteisia resursseja suojataan, että IT-järjestelmien valvomista järjestelmien resursseja koskevista säännöistä. Joskus käytetään termejä organisaatiopolitiikat (organisational policies) ja automatisoidut politiikat (automated policies) erottamaan nämä toisistaan. Pääsynvalvontaan liittyessään politiikka tarkoittaa automatisoituja politiikkoja.
Toimija (subject) tarkoittaa oliota, joka esittää pääsynvalvonnan käsittelyyn menevän pyynnön. Tässä yhteydessä voi olla hyödyllistä erottaa päätoimijan (principal) käsite: Esimerkiksi käyttäjä on päätoimija, joka käynnistää sisäänkirjautuessaan käyttäjäidentiteettiin kytkeytyviä prosesseja. Nämä prosessit ovat toimijoita ja edustavat päätoimijaa. Tällaista erottelua ei kirjallisuudessa aina tehdä eikä se ole tarpeen tässä materiaalissa. Periaatteellinen ero on kuitenkin hyvä ymmärtää, esimerkiksi heti seuraavassa määrittelyssä, jossa päätoimijan sijasta mainitaan vain käyttäjäidentiteetti.
Tietojärjestelmän toimijat luodaan esim. käyttäjän sisäänkirjautumisen yhteydessä, ja se voidaan poistaa esim. uloskirjautumisen yhteydessä. Samoin käyttäjäidentiteetit luodaan jollakin hallinnollisella toimenpiteellä, ja ne voidaan lopettaa esim. poistamalla käyttäjätili. Käytännössä toimijoiden elinikä on huomattavasti lyhyempi kuin käyttäjäidentiteettien. Teollisuuslaitoksia ohjaavat prosessit taas ovat esimerkki toimijoista, jotka voivat elää ikuisesti, paitsi jos järjestelmä kaatuu.
Kohde (object) on passiivinen olio käyttöoikeuspyynnössä. Pääsyoperaatiot (access operations) määrittävät, kuinka toimija pääsee käsiksi kohteeseen. Pääsyoperaatioihin kuuluvat esim. luku-, kirjoitus- ja suoritusoikeudet. Operaatiot voivat olla myös ohjelmia, kuten Linuxin setuid-ohjelmat, tai ne voivat olla kokonaisia työnkulkuja.
Jos päätoimijan ja toimijan erottelu on tarpeen tehdä, pääsyoperaatioiden sijasta päätoimijalla on pääsyoikeudet (access rights). Normaalisti eroa ei tarvitse tehdä eli pääsyoikeudet ja sallitut operaatiot samaistuvat. Lisäksi termiä lupa (permission) käytetään usein pääsyoikeuden synonyymina.
Joissain yhteyksissä pääsyoikeuksia kutsutaan etuoikeuksiksi (privilege). Näin tapahtuu esim. käyttöjärjestelmissä (joissa on myös etuoikeutettuja prosesseja) ja vähimpien oikeuksien periaatteessa, joka on principle of least privileges. Myös esim. Oracle9i Database Concepts Release 2 sanoo: “Etuoikeus on lupa käyttää nimettyä kohdetta määrätyllä tavalla … “.
Jotkin käyttöjärjestelmät, esim. Windows, tekevät eron pääsyoikeuksien ja etuoikeuksien välillä. Etuoikeudet ovat silloin oikeuksia käyttää järjestelmäresursseja ja suorittaa järjestelmään liittyviä tehtäviä (erotuksena esim. käyttäjän omien tiedostojen käsittelystä). Ylipäätään käyttöjärjestelmillä ja myös tietokannoilla on usein erilaisia järjestelmäoikeuksia (system privileges), joita tarvitaan järjestelmän hallintaan.
Viitemonitori (reference monitor) on komponentti, joka tekee päätökset pääsypyynnöistä käytössä olevien politiikkojen mukaisesti.
Automatisoidut politiikat¶
Automatisoidut politiikat ovat sääntökokoelmia, jotka määrittävät toimijan pääsyn kohteeseen. Politiikka voidaan ilmaista esim. pääsynvalvontamatriisina (access control matrix), jossa toimijat indeksoivat rivit ja kohteet indeksoivat sarakkeet. Kohteiden kanssa tallennetut pääsylistat (access control list) vastaavat matriisin sarakkeita ja toimijoiden kanssa tallennetut kyvyt tai kyvykkyydet (capability) vastaavat matriisin rivejä.
| kissa.jpg | paint.exe | lista.txt | |
|---|---|---|---|
| Harri | luku | ei oikeutta | luku/kirjoitus |
| Marko | luku | ajo | ei oikeutta |
| Linnea | luku/kirjoitus | ajo | luku/kirjoitus |
Yllä on esimerkki pääsynvalvontamatriisista. Toimijat ovat Harri, Marko ja Linnea. Kohteet ovat tiedostot kissa.jpg, paint.exe ja lista.txt.
Pääsynvalvontamatriisin huono puoli on, että kun järjestelmän kohteiden ja toimijoiden määrä kasvaa, myös matriisit paisuvat ja niiden ylläpito voi käydä hankalaksi. Matriisin tarkastelu on muuten hyödyllinen konteksti erottaa toimijan ja päätoimijan käsite. Matriisissa ei esitetä ohimeneviä toimijoita vaan pysyviä päätoimijoita. Yleensä ei ole ongelmaa kutsua niitäkin vain toimijoiksi.
Roolipohjainen pääsynvalvonta¶
Roolipohjaisessa pääsynvalvonnassa (role-based access control, RBAC) roolit ovat välikerros käyttäjien ja tiettyjä toimia koskevien valtuuksien välillä. Toimet voivat liittyä sisäänrakennettuihin eheystarkistuksiin, jotka välittävät pääsyn kohteisiin. Käyttäjille on määritetty rooleja ja käyttäjät ovat valtuutettuja suorittamaan käynnissä olevaan rooliinsa liittyviä toimintoja.
Kuvassa käyttäjiin liittyy jokin rooli (opiskelija, opettaja) ja rooliin liittyy erilaisia valtuuksia (lukuoikeus, ylläpito-oikeus jne.). Valtuudet liittyvät kohteisiin (oppimisalusta, opintosuoritusrekisteri). Esimerkiksi käyttäjä Olli Opiskelija pääsee lukemaan oppimisalustaa, mutta käyttäjä Oili Opettaja voi ylläpitää sitä.
Tehtävien erottaminen (separation of duties, SoD) viittaa käytäntöihin, jotka estävät yksittäisiä käyttäjiä tulemasta liian pystyviksi. Esimerkiksi taloushallinnon vanha viisaus sanoo, ettei kannata antaa kassaa ja kirjanpitoa yksiin käsiin. Esimerkkejä SoD:stä ovat säännöt, joiden mukaan
- useamman kuin yhden käyttäjän on oltava mukana tietyn tapahtuman suorittamisessa;
- käyttäjä, jolla on lupa suorittaa tietty tapahtumasarja, ei saa suorittaa joitakin muita tapahtumia;
- politiikkojen ylläpitäjät eivät saa määrätä lupia itselleen.
Staattiset SoD-säännöt huomioidaan käyttäjän roolien määrittämisessä ja dynaaminen SoD astuu voimaana, kun rooli aktivoidaan.
RBAC:in huono puoli on, että siitä voi tulla melko sotkuinen käytön myötä, koska roolit vaativat jatkuvaa ylläpitoa. Pitää miettiä, onko järjestelmään päässyt syntymään päällekkäisiä rooleja tai onko jokin rooli vanhentunut ja pitäisi poistaa. RBAC toimii hyvin niin kauan kuin jokaisella käyttäjällä on vain yksi rooli. Käyttöönotto vaatii valtavasti vaivaa roolirakenteen suunnitteluun ja roolitietojen täyttämiseen.
Attribuuttipohjainen pääsynvalvonta (syventävä)¶
Toimijaan, kohteeseen, toimijan pyytämiin toimintoihin ja joissakin tapauksissa ympäristöön (aikaan, paikkaan, laitteeseen jne.) voidaan liittää attribuutteja, jotka ovat hienojakoisempia kuin tavallisessa pääsynvalvonnassa.
Kun politiikat ja muut säännöt määrittelevät sallitut toimenpiteet suhteessa tällaisiin attribuutteihin, kyseessä on attribuuttipohjainen pääsynvalvonta (attribute-based access control, ABAC). Sekä tavanomainen että roolipohjainen pääsynvalvonta ovat tämän erikoistapauksia, ja esimerkiksi “rooleja” voidaan asettaa myös järjestelmille, ohjelmille, laitteille ym.
ABAC voidaan suorittaa sovelluksessa tai sitä tukevassa infrastruktuurissa. Sovelluksessa toteutettu ABAC voi käyttää sovelluskohtaisia attribuutteja ja operaatioita.
Koodipohjainen pääsynvalvonta (syventävä)¶
Koodipohjainen pääsynvalvonta (code-based access control, CBAC) määrittää pääsyoikeudet ajettaville tiedostoille. Politiikat voivat viitata koodin alkuperään, koodin identiteettiin (esim. suoritettavan tiedoston tiiviste (hash)) tai muihin tiedoston ominaisuuksiin sen sijaan, että viitattaisiin tiedoston ajon käynnistäneeseen käyttäjään. Koodin alkuperä voi sisältää verkkotunnuksen (domain), josta koodi on saatu, koodin allekirjoittajan identiteetin, ja tietyn nimiavaruuden (name space). CBAC löytyy Java-tietoturvamallista ja Microsoftin .NET-arkkitehtuurista. CBAC:ssa viitemonitori suorittaa yleensä pinokävelyn (stack walk) tarkistaakseen, että kaikille pinon kutsuille on myönnetty vaaditut käyttöoikeudet.
Mobiiliturvallisuus (syventävä)¶
Älypuhelimilla on yleensä yksi omistaja, ne sisältävät yksityisiä käyttäjätietoja, tarjoavat viestintätoimintoja puheluista NFC:hen (near field communication), voivat tarkkailla ympäristöään kameran ja mikrofonin avulla sekä määrittää sijaintinsa esimerkiksi GPS:n avulla. Älypuhelimissa sovellukset ovat pääsynhallinnan toimijoita. Kohteita ovat arkaluonteiset puhelimeen tallennetut tiedot ja arkaluonteiset puhelimen toiminnot.
Älypuhelimen pääsynvalvonta vastaa käyttäjän yksityisyysvaatimuksiin ja alustan eheysvaatimuksiin. Esimerkiksi Android jakaa käyttöoikeusryhmät normaaleihin, vaarallisiin ja allekirjoitusoikeuksiin. Normaalit luvat eivät aiheuta yksityisyyshuolia tai alustaan liittyviä eheyshuolia ja sovellukset eivät tarvitse hyväksyntää vaatiessaan tällaisia käyttöoikeuksia. Vaaralliset luvat voivat vaikuttaa yksityisyyteen ja vaativat käyttäjän hyväksynnän. Android 6.0:aan asti käyttäjien piti päättää sovelluksen luvat, kun sovellus asennettiin. Käyttäjätutkimuksissa kävi ilmi, että luvat annettiin liian helposti, koska käyttäjät eivät olleet tietoisia riskeistä eivätkä ymmärtäneet mitä olivat tekemässä. Android 6.0:sta lähtien käyttäjiä on pyydetty valtuuttamaan käyttöoikeus, kun sitä tarvitaan ensimmäisen kerran. Allekirjoitusoikeudet vaikuttavat alustan eheyteen, ja niitä voivat käyttää vain alustan tarjoajan valtuuttamat sovellukset. Sovellus ja lupa on allekirjoitettava samalla yksityisellä avaimella.
Digitaalisten oikeuksien hallinta¶
Digitaalisten oikeuksien hallinta (digital rights management, DRM) juontaa juurensa viihdealalle. Hallitsematon digitaalisen sisällön (esim. pelit, elokuvat tai musiikki) kopioiminen heikentäisi sisällöntuottajien ja jakelijoiden liiketoimintaa. Siksi heidän etunsa on vaikuttaa siihen, miten sisältö on saatavilla ja miten sitä voidaan käyttää asiakkaiden laitteilla. Toimintatavat voivat säännellä esim., kuinka monta kertaa sisältöä voidaan käyttää, kuinka kauan sisältöä voi tutkia ilmaiseksi, sisällön käyttämiseen tarkoitettujen laitteiden määrää, tai sisällön hinnoittelua.
DRM kääntää pääsynvalvonnan päälaelleen, koska se asettaa ulkopuolisen osapuolen politiikan järjestelmän omistajalle sen sijaan, että suojelisi järjestelmän omistajaa ulkoisilta osapuolilta. Superjakelu (superdistribution) mahdollistaa tietojen vapaan jakamisen suojatuissa konteissa (protected container). Konteissa on liitteenä käyttöehtojen leimat (label). Tietoja voidaan käyttää vain koneissa, joissa on sopiva lukija, ns. superdistribution label reader. Lukija voi purkaa kontin ja seurata (ja raportoida) tietojen käyttöä ja valvoa käyttöehtoja. Tällaisen peukaloinninkestävän (tamper resistant) täytäntöönpanomekanismin etsiminen oli yksi luotetun tietojenkäsittelyn (trusted computing) liikkeellepanevista voimista.
Vaadittu peukaloinnin eston taso riippuu odotettavissa olevista uhista. TPM-moduulit (trusted platform module) ovat korkean varmuuden antava laitteistoratkaisu. Intel SGX-järjestelmän erillisalueet (enclave) ovat järjestelmäohjelmistoratkaisu. Asiakirjanlukijat, jotka eivät salli kopioimista, toteuttavat peukaloinnin eston sovelluksessa. Tarrautuva politiikka (sticky policy) tarkoittaa, että kohteeseen liittyvä pääsynvalvontapolitiikka kulkee kohteen mukana. Esim. jos potilaan tiedot (kohde) matkaavat useissa terveydenhuoltoyksiköissä, tarrautuva politiikka varmistaa, että pääsy potilaan tietoihin toteutuu kaikissa saman politiikan mukaan, koska pääsynvalvontapolitiikka on kiinni tiedoissa.
Todistaminen (attestation) antaa luotettavaa tietoa alustan kokoonpanosta. Suora anonyymi todistus (direct anonymous attestation) toteuttaa tämän suojaten käyttäjien yksityisyyttä. Etätodistusta (remote attestation) voidaan käyttää, kun politiikka perustuu etäkoneessa käynnissä oleviin ohjelmiin. Sisällön omistaja voi esimerkiksi tarkistaa ohjelmiston kokoonpanon kohdekoneessa ennen sisällön päästämistä siihen. (Attestation on esillä myös käyttöjärjestelmän koventamisen yhteydessä.)
Käytönvalvonta¶
Käytönvalvontaa (usage control, UCON) on ehdotettu viitekehykseksi valtuuksille, jotka perustuvat toimijan ja kohteen attribuutteihin, velvoitteisiin (obligations) ja ehtoihin (conditions). Velvoitteet ovat lisätoimintoja, jotka käyttäjän on suoritettava saadakseen käyttöoikeuden, esim. linkin klikkaaminen käyttöehtojen hyväksymiseksi. Velvoitteet voivat olla myös tekoja, jotka järjestelmän on suoritettava, esim. pääsypyyntöjen lokitus. Näitä toimia täytyy mahdollisesti suorittaa ennen pääsyä, sen aikana tai sen jälkeen.
Ehdot ovat toimijasta ja kohteesta riippumattomia, esim. kellonaika, kun politiikka sallii pääsyn vain toimistoaikoina, tai pääsyä pyytävän koneen käyttöpaikan sijainti. Esimerkkejä jälkimmäisistä ovat politiikat, jotka sallivat tietyt pyynnöt vain, kun ne on lähetetty järjestelmäkonsolista, jolloin pääsy on mahdollinen ainoastaan paikallisverkon koneista, tai politiikat, jotka ottavat huomioon pääsypyynnön mukana tulevan IP-osoitteen maan. Monet UCONin käsitteet on otettu käyttöön XACML 3.0 -standardissa.
Käytönvalvonta voi sisältää myös sääntöjä siitä, mitä tapahtuu sen jälkeen, kun kohdetta käytetään, esim. asiakirja on luettavissa, mutta sen sisältöä ei voi kopioida. Säännöt voivat koskea myös sitä, miten attribuuttien ominaisuuksia voidaan muuttaa pääsyn sallimisen jälkeen, esim. uutissivusto voi pienentää vierailijalle sallittujen ilmaisten artikkelien laskuria. Voidaan ajatella myös niin, että “perinteinen” pääsynvalvonta käsittelee pääsyn perusoperaatioita infrastruktuurin tasolla, kun taas käytönvalvonta koskee kokonaisia työnkulkuja sovellustasolla. Tietoliikennepalveluissa käytönvalvonta voi asettaa rajoituksia liikenteen määrälle.
Pääsynvalvonnan käyttöönotto¶
Politiikan käyttöönotto alkaa tietysti sen määrittämisestä. Kaikille pääsypyynnöille pitää olla paikka, jossa politiikan mukaisuus ratkaistaan. Tämä saattaa vaatia lisätietoa muista lähteistä. Lopuksi päätös on välitettävä komponentille, joka hallitsee pyydettyä resurssia. XACML-terminologian mukaan tarvitaan politiikan
- hallintapisteet (policy administration points), joissa käytännöt asetetaan,
- päätöksenteon pisteet (policy decision points),
- tietopisteet (policy information points), joista voidaan tiedustella lisäsyötteitä päätösalgoritmiin, ja
- täytäntöönpanopisteet (policy enforcement points), jotka toteuttavat päätöksen.
Nämä asiat näkyvät kaaviosssa, joka yhdistää XACML- ja SAML-standardeja. Infopisteet ovat tosin hajautettuna. XACML on eXtensible Access Control Markup Language, ja SAML on Security Assertion Markup Language. Kumpikin perustuu XML-kieleen. Niitä tarvitaan vasta myöhemmillä kursseilla.
Delegointi ja peruuttaminen¶
Englannin termit delegation ja granting, valtuuttaminen ja myöntäminen, viittaavat tilanteisiin, joissa toimija saa pääsyoikeuden joltakin toiselta, siirtona tai kopiona. Termien määritelmät vaihtelevat. Valtuutus on tässä materiaalissa suomennos termille authorisation. Ristiriitaa delegoivan valtuuttamisen kanssa ei välttämättä tule, ja onhan alkuperäiset valtuudetkin joku myöntänyt. Selvyyden vuoksi valtuuksien siirrosta voi suomeksikin hyvin käyttää termiä delegointi.
Delegointi tuottaa yleensä lyhytaikaisia pääsyoikeuksia jonkin prosessin ajaksi. Esimerkiksi XACML tekee eron politiikan hallinnoinnin ja dynaamisen delegoinnin välillä toteamalla jälkimmäisen sallivan joidenkin käyttäjien luoda rajoitetun keston politiikkoja tiettyjen kykyjen myöntämiseksi toisille.
Oikeuksia ei aina myönnetä kestämään ikuisesti — vaikka kyseessä olisi järjestelmätason politiikan hallinta eikä delegointi. Esimerkiksi myöntäjä voi asettaa voimassaolon päättymispäivän, pääsyoikeus voi olla voimassa vain istunnon ajan, tai voi olla olemassa peruutusmekanismi (revocation), kuten Online Certificate Status Protocol (OCSP) on X.509-varmenteille (tarkemmin varmenteista). Kaikki yleisimmät selaimet tukevat OCSP:tä. Peruutuslistoja käytetään, kun tarkistusta ei voi tehdä verkon yli ja on etukäteen tiedossa, missä myönnettyä oikeutta tullaan käyttämään.
Viitemonitori (syventävä)¶
Alkuperäisessä merkityksessään viitemonitori (reference monitor) oli abstrakti kone, joka välitti kaikki toimijoiden pääsyt kohteisiin. Turvaydin (security kernel) oli viitemonitorin luotettava toteutus. Trusted Computing Base (TCB) oli suojausmekanismien kokonaisuus tietokonejärjestelmässä, ja se vastasi tietoturvapolitiikan täytäntöönpanosta. Sittemmin käsitteiden tulkinta on hieman muuttunut. Nykyisissä käyttöjärjestelmissä viitemonitori, esim. Windowsin Security Reference Monitor, ei ole abstraktio vaan toteutus ja TCB:lläkin saatetaan tarkoittaa samaa rajoitettua toimintoa eikä suojausmekanismien kokonaisuutta.
Viitemonitorilla on kaksi tehtävää:
- Se autentikoi (toteaa oikeiksi) kaikki toimijan pääsypyynnön yhteydessä antamat todisteet.
- Se arvioi pääsypyynnön suhteessa politiikkaan.
Kuvassa on esitetty viitemonitorin aseman pääsynvalvonnassa kuten se tulkittiin jo käyttöjärjestelmien tutkimuksessa 1990-luvulla. Kannattaa huomata, että valtuutus vaikuttaa kahteen kohtaan, kuten tämän luvun alussakin jo todettiin. Vasemmalla on valtuutettu toimija ja kohteeseen pääsee oikeutettu pääsypyyntö.
Viitemonitorin päätöksentekoalgoritmin (decision algorithm) täytyy tunnistaa sovellettavat politiikat ja säännöt ja yrittää kerätä sääntöjen viittaamat todisteet politiikan tietopisteiltä. Kun kyseessä on tilanne, jossa pätevät useat säännöt, sääntöjen yhdistämisalgoritmit määräävät lopullisen ratkaisun.
Viitemonitorien tyyppejä (syventävä)¶
Viitemonitoreja voidaan ajatella olevan kolmea tyyppiä:
- Viitemonitorit, jotka näkevät vain järjestelmäkutsut suojattuihin resursseihin, mutta eivät koko ohjelman suoritusta. Tällainen suoritusmonitori (execution monitor) on toteutettu monissa käyttöjärjestelmissä.
- Viitemonitorit, jotka voivat nähdä koko ohjelman ja analysoida sen tulevaa toimintaa ennen kuin tekevät pääsynvalvontapäätöksen.
- Kaikki ohjeet turvallisuudelle merkityksellisten operaatioiden valvonnasta on rakennettu sisään ohjelmaan. Muissa tilanteissa ohjelman tulisi toimia kuten ennenkin. Tätä in-line viitemonitoria käytetään ohjelmistoturvallisuuden yhteydessä.