Nutirakenduste turvalise arenduse suunised ja Nutirakenduste platvorminõuded on valminud Majandus- ja kommunikatsiooniministeeriumi tellimusel ja Vabariigi Valitsuse tegevusprogrammis (2011.a kinnitatud) toodud tegevuste kirjeldamiseks (Nutitelefonides rakendatavate e-teenuste turvanõuete väljatöötamine; Toetatavate nutitelefonide operatsioonisüsteemide ja brauserite valimine; Nutitelefonide operatsioonisüsteemidele ja brauseritele vastava koosvõime nõuete kirjutamine).

Dokumendi eesmärgiks on sätestada põhinõuded ja suunised, mida tuleb jälgida nutiseadmete jaoks rakenduste väljatöötamisel, sh nii riiklike tellimuste puhul kui soovi korral ka eraettevõtluses. Nutirakenduste arenduse suunised on mõeldud töövahendina kasutamiseks nii arenduste tellijale kui arendajale.

Dokument käsitleb erinevaid nutirakenduste arendusega seotud teemasid. Teemade kaupa on välja toodud põhinõuded, millega tuleb arendamisel arvestada, et lõpptulemusena valmiks turvaline ja mugavalt kasutatav mobiilirakendus, mille väljatöötamisel on arvesse võetud parimaid arenduspraktikaid.

Nutirakenduste turvalise arenduse suunised on välja töötatud projekti “Nutikaitse 2017” raames. Projekt on 2013 aasta novembris algatatud ning riigi ja erasektori koostöös läbiviidav, mille eesmärk on kaasa aidata mobiilsete e-teenuste ja lahenduste turvalisele toimimisele ja kasutamisele ajal, mil veebitoimingud on kolinud inimese taskusse.

Projekti koordineerib Vaata Maailma Sihtasutus. Koostööleppega liitujad soovivad üheskoos tõsta nutiseadmete kasutajate, arendajate ja müüjate turvateadlikkust ning kasutamisoskusi, luues seejuures võimalusi, et turvaline tarkvara oleks lihtsalt ja kasutajasõbralikult kättesaadav.

Autentimine

Tähelepanu tuleb pöörata kasutajate autentimisele ja tagada, et nutirakenduses autenditud kasutaja kasutussessioon oleks kaitstud ja seda ei oleks võimalik üle võtta.

Salasõnade turvalise käsitlemise puhul tuleb arvestada, et lisaks rakenduse arendamisel kasutusele võetud turvameetmetele, sõltub palju sellest kuidas kasutaja ise oma seadet kaitseb, sh ekraaniluku ja PIN-koodide valikust, biomeetriliste tuvastusvahendite valikust, eri teenuste puhul erinevate paroolide kasutamisest ning sellest kuidas kasutaja seadet võõraste kätte sattumise või kadumise eest füüsiliselt kaitseb.

  1. Autentimismehhanismi tugevus

    Rakendusse sisenemiseks kasutatava autentimismehhanismi tugevus peab sõltuma sellest, kui tundlikke andmeid rakendus töötleb (nt isikuandmed, rahalised toimingud). Rakenduse enda kasutajanime ja parooli kombinatsioon on kõige nõrgem autentimismehhanism. Kui kasutaja parooli valib, siis on hea anda kohest tagasisidet sisestatud parooli tugevuse kohta.

  2. 2-astmeline autentimine

    Vajadusel tuleb kaaluda 2-astmelist autentimist, st lisada autentimise protseduurile täiendavaid turvameetmeid, nt SMS kinnituskoodid, spetsiaalse võtmegenereerimise rakenduse või PIN-kalkulaatori kasutamine. Lisaks vajadusel ka CAPTCHA-koodi lisamine inimtuvastuseks.

    SMS kinnituskoodide kasutamisel on rakenduse arendajal või tellijal soovitav iga sihtturu mobiilioperaatoritelt uurida, kas SMS-ide saatmiseks kasutataval teenusepakkujal on kohalike operaatoritega sõlmitud vastavad teenuslepingud, mis tagavad autentimiskoode sisaldavate SMS-ide jõudmise lõppkasutajateni.

  3. Ristautentimine

    Kui kasutatakse delegeeritud ristautentimist (nagu OAuth), tuleks kasutada vastava standardi kõige uuemat versiooni.

  4. Kasutaja identiteet

    Kuna nutiseadmel võib olla mitu kasutajat, siis tuleb lähtuda põhimõttest, et kontrollitakse seadme kasutaja identiteeti. Ei piisa vaid kasutatava seadme identifitseerimisest.

  5. Nähtavad paroolid

    Paroolide sisestamise puhul tasub kaaluda, kas neid maskeerida tärnidega või mitte. Mitte maskeerimine võib hoopis turvalisust ja kasutusmugavust tõsta, kuna vähendab vigasid ja võimaldab inimestel kasutada keerulisemaid paroole.

    Vaata lisaks: http://www.nngroup.com/articles/stop-password-masking/

  6. Salasõna tähestik

    Kasutaja võib salasõnades kasutada ka eesti tähestiku tähti.

  7. Sisestusmuster

    Nutiseadmete puuteekraanidel tehtud näpuliigutused jätavad endast maha jäljed, mille järgi on vahel tagantjärgi võimalik tuvastada seadmega tehtud tegevusi. Vajadusel tuleb selle raskendamiseks kasutada selliseid ekraanivorme, mille puhul nt korduvalt kasutatakse sama ekraanipiirkonda, et ekraanile ei tekiks lihtsalt tuvastatavaid sisestusmustreid.

  8. Autentimise kontekst

    Autentimise turvalisemaks muutmiseks on võimalik jälgida konteksti: seadme identifiaaktorit, IP-aadresse jms. Kui rakendus tuvastab ootamatu muutuse kontekstis (näiteks IP-aadressi asukohariigi muutuse), on soovitav rakendada täiendavaid autentimismeetmeid.

  9. Paroolide salvestamine

    Paroole ei tohi seadmesse kunagi salvestada lahtise tekstina. Kui paroole on vaja seadmesse salvestada, siis tuleb kasutada seadme operatsioonisüsteemi poolt pakutavaid krüpteerimis- ja võtmehalduslahendusi.

    Paroolide seadmes hoidmise asemel tuleks kindlasti eelistada ligipääsuvõtmeid. Igasuguste otseste lõppkasutaja paroolide hoidmine seadmes, kui tegemist ei ole just eriotstarbelise rakendusega, ei ole soovitatav.

  10. Ligipääsuvõtmed

    Peale seda kui kasutaja on algselt rakenduses tuvastatud tuleks edaspidi paroolide asemel kasutada ligipääsuvõtmeid (authorization tokens). Need peavad olema seadmesse turvaliselt salvestatud, neil peab olema kindlaksmääratud aegumistähtaeg ja neid peab saama ka teenusserveri poolelt tühistada. Tuleb tagada, et ligipääsuvõtmed aeguksid nii sageli, kui see on praktikas otstarbekas (sõltub ka rakenduse eesmärgist).

  11. Sessiooniidenfikaatorid

    Kasutatavad rakenduse sessiooniidentifikaatorid peaks olema sellised, mida on keeruline ära arvata ja mida ei saa ise konstrueerida või tuletada teiste kasutussessioonide identifikaatoritest.

    Tuleb arvestada, et juhuarvude generaatorid väljastavad samasuguse sisendmuutuja (seed) puhul küll juhuslikke arve, aga need on prognoositavad. Seetõttu on oluline kasutada platvormi krüptograafiliselt turvalist juhuarvude generaatorit.

    Vaata lisaks:
    https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator

  12. Paroolide muutmine

    Rakenduse kasutajal peab olema rakendusesisene paroolide muutmise võimalus. Kõik kasutaja poolt valitud uued paroolid tuleb üle kontrollida, et tagada nende piisav keerukus (sh ka visuaalsete paroolide keerukus).

    Vt ka AKI soovitused nõuetekohase parooli valimiseks:
    http://www.aki.ee/et/soovitused-arvutikasutajale-parool-id-kaart-mobiil-id

  13. Isikutuvastuse nõusolek

    Isikutuvastusteabe edastamise nõusolek tuleb salvestada ja säilitada. See info kasutaja kohta peab olema hiljem kättesaadav.

  14. Mobiil-ID kinnituskood

    Autentimisel või allkirjastamisel kuvatav Mobiil-ID kinnituskood peab olema selgelt nähtaval ja eraldatud kohal. Kinnituskood ei tohi jääda ekraani serva taha ja kasutajal peab olema võimalus ja piisav aeg selle koodi nägemiseks ka juhul, kui selle katab hetke pärast kinni telefonis olev Mobiil-ID rakenduse dialoogiaken.

    Kontrollkoodide võrdlemine kasutaja poolt on Mobiil-ID kontseptsioonis kindlalt ette nähtud ja rõhutatud turvameede ning inimestel ei tohiks tekkida harjumust sellest mööda vaadata kui lihtsalt tähtsusetust numbrist.

  15. Mobile-ID sertifikaadid

    Rakendus võiks kasutajat teavitada Mobiil-ID sertifikaatide aegumisest, nt juhul kui aegumiseni on jäänud vähem kui 30 päeva (eeldusel, et rakendus saab Mobiil-ID sertifikaatidele ligi).

  16. Mobiil-ID teated

    Mobiil-ID kasutamise käigus kuvatavad info- ja veateated peavad olema kasutajale arusaadavad (st piisavalt informatiivsed ja mittetehnilist laadi).

  17. Kasutussessioonide logimine

    Rakenduse kasutussessioonide elutsüklisündmusi — tekkimist ja eri põhjustel lõppemist — peab logima.

  18. Väljalogimine

    Kasutajal peab olema võimalus rakendusest välja logimiseks ning kõikide ligipääsuvõtmete (tokens) eemaldamiseks. Välja logimisel peavad aeguma kõik autentimis-sessiooniga seotud sessioonid (sh. näiteks SSLi oma)

Andmete kaitse seadmes

Selleks, et viähendada seadmes asuvate andmete sh isikuandmete kolmandatele osapooltele lekkimise riski, tuleb rakenduses läbi mõelda ja kasutusele võtta vastavad riskide maandamise meetmed.

Euroopa Liidus on kohustuslik saada kasutaja nõusolek isikuandmete töötlemiseks, sh isikutuvastusteabe kogumiseks, kui seadus ei sätesta teisiti. Kasutaja peab rakendusest leidma info või viited selle kohta kuidas tema isikuandmeid töödeldakse ja milleks kasutatakse. Isikuandmete töötlemise põhimõtted peavad olema kirjeldatud “privaatsustingimustes”.

  1. Andmete tundlikkuse tase

    Nutirakenduse väljatöötamisel tuleb tellija poolt selgitada selles kasutatavate andmete, sh isikuandmete, tundlikkuse tase (nt paroolid, asukohaandmed, rakenduse töölogid). Sellest lähtuvalt tuleb kasutusele võtta sobivad turvameetmed andmete töötlemiseks ja salvestamiseks. Tähelepanu tuleb pöörata ka API-päringute kaudu liikuvate andmete turvamisele.

    Riigiasutuste puhul tuleb andmete tundlikkuse taseme selgitamisel lähtuda ISKE rakendusjuhendist, kus on kirjeldatud andmete vajaliku turbetaseme määramine.

  2. Delikaatsed isikuandmed

    Delikaatsete isikuandmete (näiteks terviseandmete) töötlemine tuleb registreerida AKIs. Soovitav on kahtluse korral täpsustada AKIga, kas on tegemist delikaatsete isikuandmetega.

  3. Minimaalselt vajalikud andmed

    Rakenduse planeerimisfaasis tuleb välja selgitada rakenduse eesmärkide saavutamiseks vajaminevad andmed sh isikuandmed, nende täpne kogumise ja säilitamise vajadus ning konfidentsiaalsusaste. Andmete kasutamisel tuleb rakendada põhimõtet, et kasutatakse vaid minimaalselt vajalikke andmeid, st üksnes neid andmeid, mis on rakenduse tööks vajalikud ja ei koguta muid andmeid.

  4. Andmete säilitusperiood

    Andmete salvestamisel tuleb määrata nende maksimaalne säilitusperiood, mille möödumisel tuleb need andmed automaatselt seadmest kustutada (et nt vältida andmete püsivat vahemällu jäämist).

    Asukohaandmeid või muud tundlikku teavet ei tohi salvestada seadmesse kauemaks, kui on vajalik rakenduse tööks.

  5. Andmete elutsükkel

    Rakenduse loomisel tuleb arvesse võtta kogu andmete elutsükli turvalisust (nende kogumine võrgu kaudu, ajutine kettale või vahemällu salvestamine, varundamine, kustutamine jne).

  6. Andmete krüpteerimine

    Tundlikke andmeid (eriti autentimisvõtmeid ja paroole) võib seadmesse ja selle vahemällu salvestada ainult krüpteeritud kujul. Võimaluse korral tuleks need salvestada muutmiskindlasse (tamper-proof) mälualasse.

  7. Krüpteerimisalgoritmid

    Tuleb kasutada kaasaegseid ja tugevaid, hästituntud krüpteerimisalgoritme (nt AES) ning konkreetseks vajaduseks sobivaid optimaalse pikkusega krüpteerimisvõtmeid.

  8. Andmete krüpteerimise meetod

    Andmete nutiseadmesse salvestamisel tuleks kasutada seadme operatsioonisüsteemi poolt pakutavat failide krüpteerimise API-t või mõne usaldusväärse tarkvaratootja vastavat lahendust.

  9. Salvestusruum

    Alati tuleb eeldada, et seadmes olev jagatud salvestusruum on ebausaldusväärne ja sellest võivad andmed kergelt või ootamatutel viisil lekkida st on ohustatud andmete terviklus (integrity), konfidentsiaalsus ja käideldavus.

    • Seadme vahemälu ja rakenduse ajutised tööfailid on võimalikud lekkekanalid, kui need on ühiskasutuses teiste rakendustega. Ajutisi või puhverdatud andmeid ei tohi hoida avalikult loetavates kataloogides.

    • Andmed võivad lekkida teiste rakendustega jagatud salvestuskohtade kaudu, sh kõnelogi, aadressiraamat või pildigalerii kaudu. Nt pildigaleriisse salvestatud piltide jagamisel võib kasutaja iseenese teadmata oma asukoha metaandmeid teistele jagada.

    • Rakenduse konfiguratsiooni võib olla võimalik modifitseerida teiste (pahatahtlike) rakenduste poolt. Isegi juhul kui konfiguratsiooniandmed ei ole konfidentsiaalsed, on rakenduse korrektse töötamise tagamiseks oluline konfiguratsiooni terviklikkuse säilimine.

  10. Andmete kustutamine

    Kuna põhimõtteliselt puudub võimalus tagada andmete kustutamine kas pilveteenusest või seadme välkmälust (kustutatakse viide andmetele ja mitte andmed ise), siis tuleb arvestada kõigi sel visiil salvestatud andmete sisuliselt piiramatu kättesaadavusega nende talletamise hetkest. Krüpteeritud andmete puhul tuleb arvestada krüptoalgoritmide efektiivsuse langust ajas: krüptitud andmete kasulikkus peab vähenema kiiremini, kui nõrgeneb kasutatud krüproalgoritm.

  11. Andmete kustutamine kaugjuhtimise teel

    Lisaturvalisuse saavutamiseks võib arendaja rakendusse lisada võimaluse andmete kustutamiseks kaugjuhtimise teel, et vajadusel oleks võimalik andmete kustutamine eraldi igas seadmes kuhu rakendus paigaldatud on (sellise võimaluse lisamine tekitab kindlasti lisariske ja selle funktsiooni kuritarvitamise ärahoidmiseks on vajalik tugev autentimine).

    Kasutajatele tuleks soovitada nutiseadmes olevate kõikide andmete krüpteerimist (kui seade seda toetab) ja seadistada turvaseaded nii, et lubatud oleks seadme tehaseseadete taastamine ja andmete kustutamine kaugjuhtimise teel (nt Android seadmetel läbi Android Device Manager keskkonna, Apple seadmetel läbi iCloud keskkonna). Autoriseerimisvõtmete võrgu kaudu edastamisel tuleb kasutada krüpteeritud andmevahetuskanalit (SSL/TLS abil, soovitavalt vähemalt TLS 1.0).

  12. Andmete varundamine

    Andmete regulaarsel varundamisel peab paroolid ja autoriseerimistunnused sellesse kaasata ainult krüpteeritud või räsitud kujul. Arvestada tuleb, et igasuguse krüpto- ja räsialgoritmi tugevus ajas kahaneb. Seega ei tohi krüpteeritud andmeid sisaldavaid tagavarakoopiaid säilitada kauem kasutatud krüptoalgoritmi efektiivsest kasutusajast.

  13. Privaatsustingimused

    Tuleb luua isikuandmete kasutamist käsitlevad privaatsustingimused ja teha need kasutajale kättesaadavaks. Rakenduses peab olema kirjeldus selle kohta milline on isikuandmete töötlemise kord ja kuidas isikuandmeid kaitstakse.

    Privaatsustingimused peavad olema rakendusest kergelt leitavad ja kasutajale arusaadavas sõnastuses. Privaatsustingimused peavad olema kättesaadavad ka sellel ekraanil, millel kasutajalt küsitakse nendega nõustumist.

  14. Sisendandmed

    Rakendus peab kontrollima kõiki sisendandmeid. Mittesobivas formaadis andmete kohta tuleb kasutajale kuvada veateade või konverteerida need sobivasse formaati.

  15. Digitaalallkirja algoritmid

    Allkirjastamisel on soovitav kasutada digitaalallkirja BDOC vormingut ja kasutada ECC krüptoalgoritmidel põhinevaid elliptiliste kurvidega (ECC) Mobiil-ID sertifikaate (kohustuslik alates 01.01.2015).

Andmete kaitse võrgus

Võrguühenduste puhul tuleks lähtuda põhimõttest, et andmete liikumine nutirakenduse ja võrgusihtpunktide vahel peab toimuma läbi krüpteeritud andmeedastuskanalite, sest arvutivõrgu kõik osad ei ole reeglina kasutaja ja rakenduse looja kontrolli all.

Suur osa nutirakendustest eeldab töötamiseks suhtlust võrgus asuvate teenusserveritega. Kui teenusserverid või ühendus nendeni ei ole piisavalt turvatud, siis see annab võimaluse nende ründamiseks läbi mobiilirakenduse.

  1. Andmete edastamine

    Teabe saatmisel igasuguse arvutivõrgu kaudu võib kasutada ainult turvalisi andmevahetuskanaleid (nagu SSL/TLS)

    Kui võimalik, tasuks kasutada laialtlevinud protokolle ning nende implementatsioone. Mida vähem erinevaid protokolle on korraga kasutusel, seda lihtsam on nii kliendi kui serveri poolel garanteerida nende töökindlus ning turvalisus.

    Näiteks enamik klient-server kasutusjuhte saab täna lahendada HTTPS protokolli kasutades, vajalikud teegid ja liidesed on laialt levinud.

  2. Sertifikaatide usaldusväärsus

    Kasutada tohib ainult usaldusväärsete sertifitseerimiskeskuste poolt allkirjastatud turvasertifikaate. Tuleb olla ettevaatlik omaallkirjastatud (self-signed) turvasertifikaatide lubamisel. SSL ühendusahela kontrollimist rakenduses ei tohi keelata ega ignoreerida.

  3. Sertifikaatide kontrollimine

    Turvalise SSL-andmeühenduskanali võib luua alles peale teenusserveri identiteedi kontrollimist, st mõlema suhtleva osapoole turvasertifikaatide usaldusväärsust on vaja enne andmete saatmist eelnevalt kontrollida.

  4. Sertifikaadi kehtivusaeg

    Rakenduse kasutajaliides peaks võimaldama turvasertifikaadi kehtivuse väljaselgitamist (kuigi kasutaja peaks seda võimalust üldjuhul nägema alles potentsiaalse veaolukorra puhul).

  5. Andmete laadimine

    Rakenduse avamisel ei tohiks koheselt käivitada mahukat andmelaadimist vaid küsida selleks kasutaja nõusolekut.

  6. Tundlike andmete edastamine sõnumiga

    Tundlikke andmeid ei tohi saata SMS-i, MMS-i või seadme teavituste kaudu.

  7. Lähiväljaside (NFC)

    Lähiväljaside (NFC) kasutamisel tuleb pealtkuulamise riski vältimiseks kindlasti kasutada sideseansi ja võimalusel ka selles liikuvate andmete krüpteerimist. Kuigi NFC on disainitud ainult lähiväljasideks, mis peaks toimima paari sentimeetri raadiuses, on ründajal siiski võimalus sideseanssi pealtuulamiseks palju kaugemalt, passiivse NFC side puhul kuni 1 meeter ja aktiivse puhul kuni 10m.

  8. Turvatestimine

    Serverites asuvatele teenusliidestele tuleks süsteemselt korraldada turvatestimist, kasutades turvadefektide leidmiseks ka automaatteste, koodianalüsaatoreid ja ründetestimise vahendeid.

  9. Serverite tugevdamine

    Tuleb tagada, et teenusserverid töötaksid tugevdatud (hardened) konfiguratsiooniga, kus operatsioonisüsteemile, veebiserverile ja muudele rakenduse komponentidele on paigaldatud uusimad turvapaigad, nendesse ei ole installeeritud mittevajalikku tarkvara, suletud on kõik mittevajalikud ligipääsuvõimalused ja ei tööta mittevajalikud serveriteenused.

  10. Teenustõkkeründed (DoS)

    Teenustõkkerünnetest tingitud riskide vähendamiseks tuleks kasutada kasutajakontode või IP-aadresside põhist andmeedastuskiiruse vähendamist ja sessioonide arvu piiramist.

  11. Teenusserverite logid

    Tuleb tagada, et teenusserverites säilitatakse piisavad logid (vajadusel ka klient-rakenduste logid) intsidentide avastamiseks ja neile reageerimiseks ning võimalike ekspertiiside tegemiseks (isikuandmete kaitseseadusega lubatud piirides).

Rakenduse kaitse

Rakenduse loomisel tuleb veenduda, et kasutatavad kolmandate osapoolte poolt loodud tarkvara valmiskomponendid on turvalised. Samuti tuleb veenduda, et liidestatavad võrguteenused on turvalised.

Nutitelefoni rakendustele saab anda automaatse juurdepääsu tasulistele funktsioonide nagu telefonikõned, SMS ja MMS, rändlusandmed, NFC maksed jne. Selliste eelisjuurdepääsuga rakenduste loomisel tuleb eriti hoolikalt võimalikke kuritarvitusi arvesse võtta. Selgitada tuleb rakenduses olevad potentsiaalsed nõrgad kohad, analüüsida mis võimalused need võimalikele ründajatele annavad ja kuidas tasulistele teenustele ligipääsu piirata.

Rakenduste turvaline levitamine mööda ametlikke rakenduste levituskanaleid on oluline. Nutiseadmete ametlikke rakendustepoode tuleb eelistada, kuna nende kaudu on kasutajatele tagatud rakenduste tarkvarauuendused ning seal on kasutusel lisakontrollid turvalisuse tagamiseks.

  1. Rakenduse eriõigused

    Rakendused vajavad seadmes töötamiseks enamasti komplekti kasutaja poolt antavaid eriõiguseid (app permissions). Enne iga õiguse küsimist tuleks põhjalikult kaaluda selle vajalikkust ning loobuda nende õiguste „igaks juhuks“ küsimisest, mida rakenduse tööks tegelikult vaja ei ole. Kasutajale peaks olema kättesaadavad täpsed selgitused selle kohta, milleks rakendus eriõiguseid vajab.

  2. Ligipääsuvõtmed rakenduse koodis

    Paroole ja muud mitteavalikku infot ei tohi sisse kirjutada mobiilrakenduse koodi, sest mobiilirakenduste kompileeritud binaarfailidest on võimalik taastada rakenduse algne lähtekood või lugeda sealt välja teenusserveritega liidestamiseks sissekirjutatud ligipääsuvõtmeid. Binaarfaili tasub käsitleda nagu avalikku ruumi.

  3. Turvatestimine

    Rakenduse turvalisus peab tulenema rakenduse disainist ja regulaarseid turvateste sisaldavast arendusprotsessist mitte lähtekoodi, turvavigade, sideprotokolli, võrguaadressi vms. salajasusel. Saladused tulevad lõpuks ikka välja.

  4. Komponentide turvalisus

    Võimaluse piires tuleb kontrollida tuleb kõikide kasutatud tarkvara valmiskomponentide turvalisust ning autentsust. Veendu, kas komponendid pärinevad usaldusväärsest allikast ja need ei sisalda võimalikke tagauksi ega pahavara. See hõlmab nii teeke kui ka Internetist kopeeritud lähtekoodi.

    Kindlam lähenemine on eraldada teiste osapoolte komponendid selliselt, et turvaaugud neis ei ohustaks rakendust. Näiteks integreeritud veebivaadetele (web view) või reklaambänneritele mitte võimaldada ligipääsu rakenduse sisefunktsioonidele.

  5. Komponentide uuendused

    Jälgida tuleb kasutatud valmiskomponentide turvaparandusi ja tarkvarauuendusi. Nende ilmumisel tuleb teha vastavad uuendused ka rakenduses.

  6. Kolmanda osapoole andmed

    Erilist tähelepanu tuleb pöörata kõikidest ebausaldusväärsetest kolmandate osapoolte rakendustest (näiteks reklaamivõrgu tarkvara) vastu võetud või neisse saadetavatele andmetele (enne nende andmete kasutamist rakenduses).

    Nagu komponentide puhul, tasub ka andmeis eeldada ebaturvalisust. Enne väljast saabunud andmete kasutamist tuleks kontrollida andmete struktuuri, tüüpide ja väärtuste vastavust ootustele. Whitelisting, ehk ainult sobivate andmete lubamine, on üldjuhul kindlam kui mittesobivate andmete keelamine ehk blacklisting. Viimase puhul võib midagi ootamatut läbi pääseda.

  7. Kasutustingimused

    Kasutajalt kasutustingimustega nõustumise nõusoleku võtmiseks on kaks peamist moodust:

    1. Rakenduse paigaldamise ajal;
    2. Rakenduse tööajal, enne nõusolekut vajavat isikuandmete töötlemist või saatmist;

    Õiguslikult on korrektne nn „optin“ lahendus, mitte „optout“, st kasutaja peab oma nõusoleku andma teadliku toiminguga, vaikimist või tegevusetust nõusolekuks ei loeta.

  8. Kasutaja identifitseerimine

    Tuleb kontrollida, kas rakendus kogub teavet mille alusel on võimalik kasutaja teadmata isikut tuvastada (see ei pruugi alati olla ilmne), näiteks kas kasutatakse unikaalseid identifikaatoreid (nt isikukood), mida kasutatakse ka mujal teenustes.

  9. Kasutustingimuste vastuolu

    Rakenduses kasutajalt võetud kasutustingimustega nõusolek ei tohi olla vastuolus mõne teise sama teenusepakkuja poolt küsitava nõusolekuga (nt mida küsitakse sama teenuse veebiversioonis). Kirjeldatud isikuandmete töötlemise kord peab käima konkreetse rakenduse kohta, mitte nt rakenduse loonud ettevõtte kohta. Samuti ei tohi see rakendusesisene kord olla vastuolus ettevõtte üldise isikuandmete töötlemise korraga. Sellised vastuolud peavad olema lahendatud.

  10. Tasuliste teenuste autentimine

    Kõik API-pöördumised seadme funktsioonidele, mis kasutavad tasulisi teenuseid, tuleb autentida (nt rakenduse väljatöötaja sertifikaadi abil). Tuleb kontrollida, et tasuliste teenuste API vastused ei edastaks lahtise tekstina teavet kliendikonto kohta, hinnastamis-, arveldus- või tooteinfot.

  11. Ostude kinnitus

    Kõikidele nutirakenduse sees raha eest teostatavatele ostudele tuleb saada kasutaja kinnitus. Samuti peab kasutajat hoiatama nende tegevuste puhul, mis eeldavad suuremahulist andmesideteenuse kasutamist (eriti roaming’u puhul) ning soovitada nende tegevuste jaoks kasutada Wi-Fi ühendust.

  12. Tasuliste teenuste kulu

    Tasuliste teenuste kasutamisel tuleb jälgida, et kasutajale kaasnev rahaline kulu oleks võimalikult väike ja kasutatakse kõiki võimalusi selle saavutamiseks. Nt minimeerida tuleb võrgus liikuvad andmehulgad, kasutada ära andmete vahemällu puhverdamise võimalusi jne.

  13. Rakenduspoed

    Kuigi rakenduste levitamisel tuleb arvestada rakenduspoodide aktsepteerimisprotsessidest tulenevate viivitustega, on neist enamik suuteline ebaturvalise koodi avastamisel ja ohu ilmnemisel rakendusi kiiresti ka kaugeemaldama. Seega on soovitav rakendusi levitada rakenduspoodide abil.

  14. Tarkvarauuendused

    Tuleb tagada, et peale rakenduse valmimist ja avalikustamist oleks sellele võimalik paigaldada uuendusi ning et vähemalt turvaprobleeme lahendavad uuendused oleksid regulaarsed ka saadaval.

  15. Tootja andmed

    Soovitav on rakendusse lisada andmed rakenduse tootja või omaniku kohta (sh üldised- ja kasutajatoe kontaktandmed).

  16. Tagasisidekanalid

    Rakenduse kasutajatele tuleb luua tagasisidekanalid turvaprobleemidest teatamiseks, näiteks luua eposti aadress algusega „security@” (ja sellest kontaktivõimalusest kasutajaid ka teavitada).

  17. Koodiinterpretaator

    Rakenduses sisalduv koodiinterpretaator peab töötama minimaalselt vajalike õigustega, et rakenduse vahendusel ei saaks teostada suuremaid õiguseid nõudvaid toiminguid (nt juhul kui rakendust proovib ära kasutada pahavara või sellesse sisestatakse modifitseeritud sisendandmed).

  18. Koodiinterpretaatori liivakasti-režiim

    Rakenduses olevatele sisendkoodi interpreteerivatele osadele tuleb teha ründetaluvuse test. Sisendkoodi interpreerivad osad tuleks paigutada nn liivakasti-režiimi (sandboxed mode).

Mõisted ja viited

ENISA
http://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-applications/smartphone-security-1/smartphone-secure-development-guidelines
OWASP Application Security Verification Standard (2014)
https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf
Nutirakendus
Nutiseadme jaoks välja töötatud rakendusprogramm (app) või nutiseadme jaoks kohaldatud veebirakendus.
Nutiseade
Mobiilne seade (üldjuhul nutitelefon või tahvelarvuti), mis erineb lihtsast mobiiltelefonist selle poolest, et võimaldab kasutada tavaarvutile omaseid funktsioone. Nutiseadmel on tavaliselt puutetundlik ekraan, internetiühendus ja operatsioonisüsteem, mis võimaldab kasutada allalaetavaid nutirakendusi.
Mobiil-ID
Mobiil-ID on Eesti Vabariigi ID-kaardil põhinev isikusamasuse tõendamise ning digitaalse allkirjastamise lahendus, mis võimaldab kasutajal end mobiilseadme vahendusel autentida.
Isikuandmed
Isikuandmed on mis tahes andmed tuvastatud või tuvastatava füüsilise isiku kohta, sõltumata sellest, millisel kujul või millises vormis need andmed on.

Isikuandmete, sh delikaatsete isikuandmete, kaitset reguleerib Isikuandmete Kaitse Seadus.

Delikaatsed isikuandmed
Delikaatsed isikuandmed on:
  • Poliitilisi vaateid, usulisi ja maailmavaatelisi veendumusi kirjeldavad andmed, välja arvatud andmed seadusega ettenähtud korras registreeritud eraõiguslike juriidiliste isikute liikmeks olemise kohta;
  • Etnilist päritolu ja rassilist kuuluvust kirjeldavad andmed;
  • Andmed terviseseisundi või puude kohta;
  • Andmed pärilikkuse informatsiooni kohta;
  • Biomeetrilised andmed (eelkõige sõrmejälje-, peopesajälje- ja silmaiirisekujutis ning geeniandmed);
  • Andmed seksuaalelu kohta;
  • Andmed ametiühingu liikmelisuse kohta;
  • Andmed süüteo toimepanemise või selle ohvriks langemise kohta enne avalikku kohtuistungit või õigusrikkumise asjas otsuse langetamist või asja menetluse lõpetamist.

Delikaatsete isikuandmete töötleja peab delikaatsete isikuandmete töötlemise registreerima Andmekaitse inspektsioonis va juhul kui ta on määranud isikuandmete kaitse eest vastutava isiku. Isikuandmete kaitse eest vastutava isiku määramisest ja tema volituste lõppemisest tuleb viivitamata teavitada Andmekaitse Inspektsiooni.

Isikuandmete, sh delikaatsete isikuandmete, kaitset reguleerib Isikuandmete Kaitse Seadus.

API
API (Application Programming Interface) on tarkvaraprogrammi rakendusliides, mis võimaldab tarkvararakendustel omavahel suhelda, kasutades selleks kindlaksmääratud reeglistikku (suhtlusprotokolli).
Teenusserver
Käesolevas dokumendis loetakse teenusserveriks nutiseadmest väljaspool asuvat teenusepakkuja tugiteenuste komplekti, mis on vajalik nutirakenduse täielikuks toimimiseks.
ISKE
Riigi poolt väljatöötatud „infosüsteemide kolmeastmeline etalonturbe süsteem“, mis on loodud eelkõige riigi ja kohaliku omavalitsuse infosüsteemidele ning nendega seotud infovaradele turvalisuse tagamiseks. ISKE väljatöötamisel ja arendamisel on aluseks võetud Saksamaa BSI (Bundesamt für Sicherheit in der Informationstechnik) avaldatav infoturbe standard (IT-Grundschutz).
AKI
Andmekaitse Inspektsioon
RIA
Riigi Infosüsteemi Amet