| permalink | layout |
|---|---|
Uuring |
Lihtne |
Autentimisteenuse turvauuring {: .pais}
{: .no_toc}
kavand 0.2, 27.10.2017
- TOC {:toc}
autentimine, kasutaja isiku tuvastamise toiming (tehniliselt täpsemas tähenduses: isikusamasuse tuvastamine).
autentimine kui teenus, arhitektuurimuster, kus rakendus ei autendi kasutajat ise, vaid delegeerib autentimise eraldiseisvale e-teenusele.
e-teenus, asutuse poolt kasutajale, sh välismaalasele pakutav e-teenus.
kasutaja, e-teenust kasutav füüsiline isik.
rakendus, asutuse veebirakendus, mis pakub e-teenust; koosneb kahest osast: 1) kasutaja sirvijasse laetav osa; 2) serveripoolne osa.
sisselogimine, (sign-on, sign-in), toiming, millega kasutaja isik tuvastatakse ja luuakse seanss kasutaja ja rakenduse vahel.
ühekordne sisselogimine, (single sign-on, SSO), arhitektuurimuster, kus kasutaja saab ühe sisselogimisega kasutada mitut e-teenust.
ühekordne väljalogimine (single sign-off), arhitektuurimuster, kus kasutaja logitakse ühe väljalogimisega välja mitmest e-teenusest.
seanss, ka sessioon, ajas piiratud suhe kasutaja ja rakenduse vahel. Võib alata sisselogimisega aga ka lihtsalt sirvijas esimese pöördumisega rakenduse poole; võib lõppeda väljalogimisega, aga ka sirvija sulgemisega või seansi ühepoolse lõpetamisega rakenduse poolt.
seansihaldus, ka seansi pidamine, seansi loomise, hoidmise, turvamise ja lõpetamise toimingud.
Käesolevas lähteülesandes kasutatakse ka veebilehel https://e-gov.github.io/TARA-Doku/Sonastik määratletud mõisteid.
Autentimistoiming on protseduur, mis lõpeb autentimissündmusega. See on hetk, kus jõutakse selge ja ühemõttelise tulemuseni — isik kas loetakse tuvastatuks või mitte, kolmandat võimalust ei ole.
Autentimisteenus võib olla — ja sageli ongi — seotud täiendavate teenustega:
-
autentimisteenuste vahendamise teenus. Teenus koondab ja teeb rakendusele kättesaadavaks erinevate teenuseosutajate autentimisteenuseid.
-
kasutaja rollide väljaselgitamise teenus. Näiteks, autentimisteenusega võib olla ühitatud päring äriregistrisse. Autentimise tulemus siis sisaldab kasutaja esindusõiguste nimekirja.
-
rolli valimise teenus. Näiteks autentimisdialoogis valib kasutaja ühtlasi organisatsiooni, kelle nimel ta tegutseb.
-
kasutajat kirjeldavate tunnuste (atribuutide) väljastamise teenus. Minimaalsel juhul tekib autentimissündmuses väga väike teabekogum: tuvastatud isiku identifikaator, nimi, autentimise aeg, mõned konteksti kirjeldavad andmed. Tihti soovitakse, et koos autentimisega selgitatakse välja rohkem kasutajaga seotud andmeid. Rakendus võib kasutajaandmeid käia autentimisteenusest isegi hiljem pärimas (nt OpenID Connect protokollis UserInfo otspunkti kaudu).
-
kasutaja nõusoleku võtmise teenus. Kasutaja nõusoleku andmine on tihedalt seotud isiku tuvastamisega. Seetõttu teostatakse need funktsionaalsused tihti koos. Kasutaja nõusolek (user consent) võib olla antud andmete töötlemiseks või ka muuks. OAuth 2.0 ongi eelkõige kasutaja nõusoleku võtmise protokoll, kus autentimine on vaid nõusoleku võtmise kaasnähtus.
-
sessioonihalduse teenus. Lihtne autentimisteenus piirdub ühekordse autentimistoimingu läbiviimisega. Autentimistoimingu tulemuseks on rakendusele väljastatav teave autentimissündmuse kohta (OpenID Connect protokollis identsustõendi vormis). Seansi loomisega ega hoidmisega lihtne autentimisteenus ei tegele. Sessioonihaldust sisaldav autentimisteenus võtab enda kanda ka sessiooni haldamise tegevusi, nt kasutaja perioodiline uuesti autentimine, seansi aegumise jälgimine jms.
-
ühekordse sisselogimise teenus.
-
ühekordse väljalogimise teenus.
Laiemas tähenduses võib kõiki neid teenuseid nimetada autentimisteenusteks. Loetelu ei ole lõplik. Lisada võib kasutusstatistika tootmise teenuse jm. Autentimisteenuse kavandamisel peab endale aru andma, kas eesmärk on piiratud funktsionaalsuse teenus või üksteisega seotud teenuste kobarat pakkuv identiteediplatvorm. Viimane nõuab hoopis suuremaid võimekusi ja ressursse nii arenduses kui ka käitluses.
Tähtis on ka autentimisteenuse ulatus organisatsioonilisel tasandil. Olulised momendid on kas autentimisteenus ületab asutuse piire, kas autentimisteenus on mõeldud kohustuslikuna ja kuidas autentimisteenus suhtestub asutuste olemasolevate autentimislahendustega. Vastavalt eristame:
-
asutusesisene autentimisteenus, kus teenuse osutaja ja kasutaja on üks ja sama asutus
-
asutuseväline autentimisteenus, kus asutus kasutab, võimalik, et ühe alternatiivina, teise asutuse osutatavat teenust
-
keskne autentimisteenus, avaliku sektori ühtne autentimisteenus, mida kõik asutused, võimalik, et vaid väheste eranditega, on kohustatud kasutama.
Kokkuvõte. Autentimisteenust on võimalik osutada nii lihtsa teenusena kui ka osateenustest koosneva laiahaardelise kogumina (platvormina). Oluline küsimus on kas ja millist osateenuste buketti pakkuda, mida erineva ulatusega teenuse pakkumine tähendab, milliseid võimekusi nõuab ja milliseid riske sisaldab — ja kuidas riskid maandatakse ja võimekused luuakse.
Laiemate võimalustega autentimisteenuse kavandamine nõuab riskianalüüsi. Üldistatud kujul on riskid järgmised:
-
teenuse järele ei ole reaalset vajadust
-
kasutaja ei saa teenusest aru
-
asutuste võimekus (organisatsiooniline, finantsiline, tehniline) teenust kasutusele võtta on madal
-
valitud tehniline kontseptsioon osutub ebaturvaliseks
-
valitud tehniline kontseptsioon osutub mitteteostatavaks
-
valitud tehniline kontseptsioon osutub mittejätkusuutlikuks
-
turul ei leidu kompetentset, huvitatud arendajat
-
turul ei leidu kompetentseid liidestuste arendajaid
-
RIA võimekus teenuse arendust tellida osutub ebapiisavaks
-
RIA võimekus teenust käitada osutub ebapiisavaks
-
teenus kokkuvõttes ei tasu end ära.
Keskse autentimisteenuse on loonud paljud riigid [1][2]. Välisriikidest on eeskujuna meile olulisim Soome. Suomi.fi autentimisteenus toetab ühtset sisselogimist [2]. Eestis on keskne autentimisteenus seni puudunud. RIA on 2017. a sügisest aktiivselt arendanud keskset autentimisteenust TARA [3]. Esimeses, juba käivitunud järgus pakub TARA ainult lihtsat, ühekordse sisselogimiseta autentimisteenust. Ühekordse sisselogimisega autentimisteenust on RIA-s kavandatud, vaheaegadega, alates 2015. a. Tulemusena on valminud kavand [6], mis käsitleb küll tehnilist külge, kuid ei sisalda ärivajaduse ega turvalisuse analüüsi.
Uuringu eesmärk on analüüsida Open ID Connect raamistikul baseeruva autentimisteenuse tehnilisi, protseduurilisi ja ärilisi riske erinevatel teenuse ulatuse tasemetel ning leida ja kirjeldada riskide maandamiseks vajalikud meetmed.
[1] Lätis on keskne autentimisteenus tihedas kasutuses.
[2] Soomes on loodud keskne Suomi.fi autentimisteenus, mille võtavad kasutusele kõik keskvalitsuse asutused. Vt https://tunnistaminen.suomi.fi/sivut/info/tietoapalvelusta/.
[3] Riigi Infosüsteemi Amet (2017) TARA autentimisteenus, https://e-gov.github.io/TARA-Doku/.
[4] TARA autentimisteenus. Teekaart https://e-gov.github.io/TARA-Doku/Teekaart.
[5] TARA autentimisteenus. Tehniline kirjeldus https://e-gov.github.io/TARA-Doku/TehnilineKirjeldus.
[6] Riigi Infosüsteemi Amet. RIA SSO autentimisteenuse kavand. 18 lk. https://github.com/ria-eidas/RIA-autentimisteenus/wiki/Teenuse-kontseptsioon.
[7] OpenID Foundation (2017) OpenID Connect Session Management 1.0. Draft 28. http://openid.net/specs/openid-connect-session-1_0.html.
[8] OpenID Foundation (2017) OpenID Connect Front-Channel Logout 1.0. Draft 02.
http://openid.net/specs/openid-connect-frontchannel-1_0.html.
[9] OpenID Foundation (2017) OpenID Connect Back-Channel Logout 1.0. Draft 04. http://openid.net/specs/openid-connect-backchannel-1_0.html.