Mittefunktsionaalsed nõuded v 4.1

Nõuete rakendamisel arvestada konkreetse tarkvara eripära.

Rakenduvad ainult need nõuded, mida konkreetse tarkvara iseloomu, ülesehituse ja kasutatavate komponentide kontekstis on mõistlik rakendada.

Nõudeid rakendada hierarhia põhimõttel.

RIA MFN-i nõudeid tuleb rakendada kõigis RIA infosüsteemides. Valdkonna MFN määratleb valdkonna tarkvara spetsiifilised nõuded. Hanke MFN-i nõuded täpsustavad ja täiendavad asutuse või valdkonna nõudeid. X-tee tuumtarkvara arendatakse ühiselt Soome riigiga. Vastavalt on ka MFN inglise keeles ja avaldatud Soome partnerasutuse GitHub-repos: X-Road Non-Functional Requirements. RIHA nõuded asuvad arhitektuuriteatmikus.

Andmebaasides ja rakendustes kasutada UTF-8 kodeeringut.

Ühe faili piires kasutada alati sama reavahetuse kodeeringut - kas Windowsi (CR+LF; 0x0D0A; U+000D U+000A) või Linux/Unix standardile vastavat (LF; 0x0A; U+000A).

Aja esitamisel andmevahetusprotokollides kasutada Internet Date/Time vorminguid (RFC 3339 Date and Time on the Internet: Timestamps). Aja esitamisel inimkasutajale lähtuda vastava keele reeglitest (eesti keele puhul Eesti õigekeelsuskäsiraamat 2019, ptk “Arvukirjutus”).

Nt: “1961-07-12T10:05:00Z”, “2020-02-18T09:31:20.463+02:00”. Märkus. Mõned standardid nõuavad aja esitamist Unix epoch vormingus, nt: 1) nt OpenID Connect ja 2) W3C veebiliidesed.

Tarkvara markeerida litsentsiga.

Teose autoriõigused tuleb selgelt välja tuua. Standardseks vahendiks selleks on litsents. Litsents esitatakse ühel või mõlemal alljärgnevatest viisidest: 1) LICENCE-fail repos; 2) litsentsi tekst iga faili päises. RIA põhimõte on arendada tarkvara avatult ja avaldada tarkvara vaba litsentsiga. Erandid turva- jm õigusega pandud piirangute korral. Soovitatav on kasutada MIT litsentsi - nii tagatakse paremini tarkvarade litsentsiline ühtesobivus. Alternatiiv on EUPL.

Tarkvara arendamisel lähtutakse avatuse ja vaba lähtekoodi põhimõttest.

Välja arvatud õigusest tulenevad piirangud (turvameetmed, andmekaitse, ärisaladuses).

Rakenduse välissõltuvused peavad olema ilmutatult, selgelt välja toodud.

Rakendus peab olema väliste süsteemide tõrgete suhtes vastupanuvõimeline (resilient).

Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist.

Rakendus peab olema tehniliselt tükeldatud vastavalt loogilisele jaotusele. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavad. Muuhulgas peab andmebaas olema rakendusest eraldi paigaldatav.

Näiteks, kui rakendusel on eraldi turvakontekstidega liidesed ametnikule ja kodanikule, peab rakendus olema jaotatud kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks.

Rakenduse funktsionaalsuses tuleb selgelt eraldada avaliku teenuse liides muudest mitteavalikest, sisemistest, konfigureerimis jms. liidestest.

Kõik liidesed rakenduse eri osade vahel peavad olema vajadusel kaitstavad kahepoolset tuvastamist ja krüpteerimist võimaldava protokolliga.

Rakenduse pakutav(ad) HTTP REST masinliidesed (API-d) kirjeldatakse masinloetavas OpenAPI vormingus.

Masinloetav kirjeldus ei välista täiendavat, paremini inimloetavat vabavormilist kirjeldust.

Lähtekoodi dokumentatsioon, lähtekood ise ning logiteated peavad olema inglisekeelsed.

Rakendustes kasutatud eestikeelsetele tekstidele kehtivad infotehnoloogia reeglid Eesti keele ja kultuuri keskkonnas EVS 8:2008.

Lähtekood peab olema varustatud ühiktestidega.

Tarkvara peab olema enne toodangusse paigaldamist läbinud turvatestimise.

Alates integratsioonitasemest peavad automaattestid olema parameteriseeritud.

Automaattestid peavad raporteerima tulemusi inim- ja masinloetaval kujul (näiteks JUnit XML ja HTML).

Automaatteste käivitatakse RIA CI vahendi Jenkins vahendusel.

Lõplik kood peab olema läbinud staatilise koodianalüüsi.

Kasutada otstarbekat tööriista: Java puhul Checkstyle, PMD, SonarQube vms; Javascripti puhul ESLint. Samuti kasutada arendusredaktoritesse sisseehitatud kontrollijaid.

Stiiliteave asetada CSS-failidesse.

Stiile ei tohiks sisse kirjutada HTML-teksti, ei style-taagide vahelise tekstina ega style-atribuutidena.

Mahukate laadilehtede puhul kaaluda Sass-i kasutamist.

Sass võib suurendada laadilehtede loetavust ja hallatavust.

Järgida ajakohaseid veebistandardeid.

HTML5, CSS3 jms.

Rakendus peab töötama veebisirvijates, mis toetavad eID baastarkvara kaht viimast versiooni.

Vt sirvikute loetelu ID-tarkvara abikeskuse lehel ID-tarkvara paigaldamine.

Veebisirvija toe puudumisel andku rakendus veateate.

Kui kasutajaliides, mille poole kasutaja pöördub, ei ole ühilduv kasutatava veebisirvijaga, peab rakendus arusaadaval ja juhendaval viisil sellest kasutajat teavitama.

Veebirakenduse kasutajaliides peab olema juurdepääsetav. Tuleb täita WCAG 2.2 taseme AA nõuded.

Vt: Web Content Accessibility Guidelines (WCAG) 2.2. (Eestikeelne tõlge on olemas v2.0 kohta: Veebi sisu juurdepääsetavussuunised (WCAG) 2.0). Vt ka: 1) EL standard EN 301 549 Accessibility requirements for ICT products and services; 2) ettevõtlus- ja infotehnoloogiaministri määrus Veebilehe ja mobiilirakenduse ligipääsetavuse nõuded ning ligipääsetavust kirjeldava teabe avaldamise kord.

Kasutada selge, ühtse mustriga, inimloetavaid veebiaadresse (URL-e).

Igal lehel peab olema unikaalne veebiaadress.

URL ei tohi sisaldada isikuandmeid.

Võimalikud on erandid, kui isikuandmete kaitseks on rakendatud asjakohaseid tehnilisi ja organisatsioonilisi meetmeid. Meetmetega peab tagama kaitse vähemalt järgmiste riskide vastu: isikuandmete lekkimine sirviku ajaloost, HTTP seansi pealtkuulamine, isikuandmete lekkimine vahendusserveri (proxy) logist, isikuandmete lekkimine serveri logist.

URL ei tohi sisaldada sessioonivõtit.

Vea- jm teated peavad oleva arusaadavad.

Muuhulgas peab rakendus asendama vaikimisi veateate (404 vms) lehekülje, kuid säilitama algse HTTP vastuskoodi.

Veasituatsioonid tuleb varustada veakoodidega. Kasutajale tuleb esitada koos veateatega ka veakood.

Veateated tuleb logida.

Objektid identifitseerida registrikoodide abil.

Riiklikesse registritesse kantavad objektid (isikud, katastriüksused jne) kantakse andmebaasi nende registrikoodiga, mida täiendab riigiprefiks vastavalt ISO3166-1 Alpha 2 standardile. Näiteks isikute sidumiseks süsteemi kasutajakontoga peab kasutama isikukoodi rahvastikuregistrist.
Eesti Vabariigi kodanik identifitseeritakse Eesti Vabariigi poolt väljastatud eIDga. Igasuguse muu identifitseerimisevahendi kasutamine peab olema selgelt põhjendatud.
Mittekodanike isikuidentifikaator saadakse järgmisel viisil: riigikood + sookood + sünniaeg + [ dok_nr | id_riigis ], kus
riigikood - kolmekohaline ISO 3166-1 Alpha-3 standardile vastav riigi kood
sookood - soo identifikaator nii nagu Eesti Vabariigi isikukoodis
sünniaeg - sünniaeg formaadis YYYYMMDD
id_riigis - kui see on olemas, tuleb kasutada isiku koduriigi isikuidentifikaatorit. 16 kohta, 0-polsterdatud vasakult
dok_nr - kui isiku koduriigis isikuidentifikaatorit ei ole, siis kasutatakse isiku dokumendi numbrit. Dokumendi number, 16 kohta, 0-polsterdatud vasakult.

Rakendus ei tohi luua uut identiteedisüsteemi. Tuleb tugineda olemasolevatele riiklikele (ID-kaart) või põhiliste op-süsteemide süsteemidele (Kerberos jms).

Rakendada aadressiandmete süsteemi nõudeid.

Eesti aadressiandmete sisestamisel, kuvamisel ja hoidmisel lähtuda Vabariigi Valitsuse 8. oktoobri 2015. a määrusest nr 103 „Aadressiandmete süsteem“.

Rakendada klassifikaatorite süsteemi nõudeid.

Eesti tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel lähtuda Vabariigi Valitsuse 10. jaanuari 2008. a määrusest nr 11 „Klassifikaatorite süsteem“ ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit.

Väliste kasutajate, so. Eesti Vabariigi residentide ja EL teiste liikmesriikide residentide autentimislahenduse loomisel lähtuda dokumendist Autentimislahendustele kehtivad nõuded.

ID-kaardiga autentimisel ei kasutata serdi edastamise päises side- (-) ega alakriipse (_).

Rakenduse mitteavalike osade kasutajate rollid asuvad rakendusevälises LDAP serveris või muus autentimislahenduses. Süsteem ei tohi realiseerida omaenda rollide haldamist.

Süsteemist väljumine peab toimuma sõnaselgelt, kasutajale arusaadaval ja turvalisel viisil.

Kasutaja saab süsteemist väljuda kahel viisil: tema sessioon on pikem, kui sessiooni pikkuse seadistatav piirväärtus (eraldi määratletavad piirangud kogu sessioonile ning tegevuseta perioodile sessioonis) või kasutaja lõpetab sessiooni enda algatusel.

Juhul kui rakenduse turvanõuded näevad seda ette, peab olema võimalus koheselt lõpetada kasutaja sessiooni nii, et kasutaja saaks arusaadava ja põhjendatud teate sessiooni lõpetamise kohta.

Andmebaasi kasutaval rakendusel on vähemalt kaks andmebaasikasutajat:
<rakendus> nimeline andmebaasi skeem kuulub andmebaasi kasutajale <rakendus> (roll db owner, skeemid ja seal paiknevad objektid kuuluvad sellele kasutajale).
<rakendus> nimelises andmebaasi skeemis on defineeritud <rakendus>_app nimeline kasutaja, kes omab ligipääsu (SELECT, INSERT, UPDATE, DELETE) ainult rakenduse käitamiseks vajalikele tabelitele, protseduuridele või funktsioonidele.

Nõue tuleneb eelkõige sellest, et vahel kasutame andmebaaside ““koosmajutamist” s.t erinevate süsteemide või ka ühe süsteemi erinevate komponentide (mikroteenuste) andmebaase hoiame ühes PostgreSQL instantsis. Sellisel juhul on vaja tagada eristatus: iga andmebaas peab olema eraldi skeemis; rakendus ei tohi teise rakenduse skeemile ligi pääseda (suheldakse API-de kaudu); rakendus ei tohi ise skeeme moodustada s.t skeemi tohib moodustada ainult paigaldusprotsess. Ka siis, kui koosmajutust hetkel ei kasutata, on eristamine hea praktika.

Ühest andmetabelist teise viitamisel tuleb kasutada välisvõtmeid (foreign key). Kõik välisvõtmed peavad olema indekseeritud mitteunikaalse indeksiga ja välisvõtmetena kirjeldatud.

Kõigis andmebaasi tabelites peab olema defineeritud integer-tüüpi või UUID-tüüpi primaarvõti, mis on surrogaatvõti. Primaarvõtmena ei tohi kasutada reaalse eluga seotud andmevälju.

Kõik primaarvõtmed (primary key) peavad olema indekseeritud unikaalse indeksiga.

Kui andmebaasis olevate andmete ISKE tervikluse klass on 2 (E-ITS rakendamisel IS) või kõrgem, siis tuleb kõik klass 2 infot sisaldavad andmebaasi kirjed versioneerida.

Andmebaasi väljade pikkused tuleb andmekirjelduskeeles (DDL-is) kirjeldada sümbolites, mitte baitides.

Päringulaused ei tohi sisaldada konstantidena sisse kirjutatud päringutingimuse võrdlusväärtusi.

Kasutada päringumuutujaid (variable binding).

Andmebaasi objektide nimetused peavad olema inglisekeelsed. Nimetused tohivad sisaldada ainult Latin1 (ISO8859-1) kodeeringu tähti a-z; A-Z, numbreid 0-9, ning alakriipsu _. Objektide nimetused ei tohi alata numbritega. Andmebaasiobjektide nimed peavad olema semantilised st. objekti tähendust avavad.

Rakendus peab olema tabelite partitsioneerimise suhtes agnostiline st. tabelite partitsioneerimisstruktuuride muutmine ei tohi mõjutada rakenduse tööd.

Rakendusserveri, nt Tomcat kasutamisel, tuleks võimalusel kasutada rakendusserverit ka andmebaasiühenduste (JDBC) halduseks.

Rakendus ei puuli ise, vaid küsib JNDI abil rakendusserveri puuli aadressi. Nõude eesmärk on jõudluse parem hallatavus.

Rakenduse logimine peab olema organiseeritud kasutades selleks ettenähtud standardseid vahendeid viisil, mis võimaldab rakenduse administraatoril määratleda ja muuta logide väljundit (vähemalt fail, andmebaas, syslogd), logimise taset ja logimise formaati.

Java rakenduste korral logitakse SLF4J raamistiku abil.

Ühtlustatud selleks, et rakendusi saaks seadistada ühtemoodi.

Logid kirjutatakse inglise keeles (välja arvatud kasutajale näidatud teated).

Turvalisuse seisukohalt kriitilised sündmused (sisenemine, väljumine, rolli muut(u)mine) ning tegevused, mis toovad kaasa rahalisi või juriidilisi tagajärgi, logitakse eraldi konfigureeritavasse turvalogisse.

Telemeetria.

Infosüsteemi arendustes tuleb juhul, kui otsustatakse rakendada kasutaja teekonna (ja muu telemeetria) kogumist, juhinduda CNCF OpenTelemetry spetsifikatsioonidest. Vt: https://opentelemetry.io ja https://github.com/open-telemetry/opentelemetry-specification.

Rakenduse (RIA poolt hallatavasse serverisse) pakendamine, paigaldamine, uuendamine, muudatuse taastamine ja testide käivitamine peavad olema automatiseeritud standardse üldkasutatava vahendi abil.

Kasutusel on Maven ja Jenkins.

Ehitatud paki nimi peab sisaldama projekti nime ja paki versiooni ning tohib sisaldada ainult tähemärke [a-z;0-9] ja - (miinus) ja _ (alakriips) (nt projektinimi-1_0_23).

Pakk peab olema keskkonnaagnostiline s.t arendus-, toodangu- jm keskkondade jaoks normaalselt ei tehta eraldi pakke. Tarkvara muutub konkreetse keskkonna osaks pärast keskkonda paigaldamist ja keskkonnas seadistamist.

Rakendused ehitatakse ja paigaldatakse ainult lähtekoodihoidlast, selle üheselt viidatud harust.

Kood tarnitakse RIA taristus olevasse reposse. Koodi võib tarnida GitHubi, juhul kui on seadistatud GitHubi repo peegeldamine RIA sisereposse. Kumba meetodit kasutatakse, määrab RIA.

Lähtekoodi kompileerimine peab olema teostatav ka välisvõrguühenduse puudumise korral. Selle nõude täitmise võimaldamiseks on RIAs kasutusel sisemised tarkvarakomponentide repod.

Vt täpsemalt sisenõuete dokumendist.

(kehtetu)

Java rakenduse tööks vajalikud teegid peavad olema rakenduse osa. Kui Java rakenduse käitamiseks on kasutatud mõnd rakendusserverit (näiteks Tomcat), siis võivad selle tööks vajalikud üldteegid olla rakendusserveri lib kaustas.

Näide: JNDI konfiguratsioon eeldab, et andmebaasiohjur oleks rakendusserveri sees (nt. Tomcat), mitte rakenduse WAR failis. Juhul kui andmebaasiohjur on osa WAR failist, võib andmebaasiühenduste probleemide tekkimisel kohe tekkida ka probleem rakendusserveri (taas)käivitamisega.

Fondid, laadilehed ja Javascripti failid serveerida rakendusest endast.

Toodangusse evitatavas tarkvaras peavad sõltuvuste versioonid olema fikseeritud.

Eesmärgiks on ehitamise korratavus (repeatable build). Näiteks: Node.js platvormil toodangusse evitatavate moodulite package.json failis, jaotises dependencies ei tohi olla versioonimärkeid ^, ~, *, x.

Rakendus saadab e-kirju RIA SMTP edastusteenuse kaudu.

Täpsemad nõuded vt SMTP edastusteenuse kirjeldusest.

Rakendus peab olema loodud sõltumatuna rakendusserveri tarkvarast.

Rakendust peab olema võimalik konfiguratsioonimuudatuste abil paigaldada teisele samatüübilisele rakendusserverile. Kui see ei ole võimalik tuleb rakendusele luua sobituspaketid põhiliselt kasutatavate rakendusserverite jaoks.

Kõik rakenduse versiooniuuendused (sealhulgas muudatused andmebaasi struktuuris ja koodis) peavad kuni järgmise versiooniuuenduseni olema täielikult tagasi pööratavad st. koos versiooni uuendusega peavad olema loodud vahendid ja kirjeldatud protseduurid versiooniuuenduse tagasi võtmiseks.

Rakendus ei tohi eeldada paigalduskeskkonna turvalisust.

Rakendusservereid peab olema võimalik lisada teenust pakkuvasse klastrisse ja sealt eemaldada vastavalt vajadusele.

Rakendus ei tohi kasutada konfigureerimata viiteid failidele või välistele süsteemidele st. kõik viited peavad olema programmikoodi välised.

Kõik andmebaasiühendused tuleb kirjeldada täispika URI abil. Java rakendustes kasutatakse JNDI ühendusi.

Andmebaasi JNDI objekti Datasource-i nimetamisel tuleb kasutada prefiksit jdbc ning ühesõnaliste lühendite korral väiketähti. Nt: jdbc/system1, jdbc/system2 jne.

Rakenduse andmebaasi või andmeskeemi paigaldamine ei tohi nõuda punktis erilisi kasutajaõigusi.

Kui ei ole määratud teisiti, peab rakendus olema kasutatav ISKE klassile K2T2S2 (E-ITS rakendamisel - samaväärsele turbetasemele) vastavate süsteemide loomisel.

Turvameetmetega tutvu ISKE portaalis, E-ITS rakendamisel - E-ITS portaalis.

Süsteem ei tohi võimaldada kasutajale ligipääsu süsteemi toimimise informatsioonile, nagu failide täisnimed, kutsepinud (stack trace) jms.

Kaitsmata avalik võrguliiklus ei ole lubatud. Igasugune avalik võrguliiklus on krüpteeritud. TLS keskkonna parameetrid on administraatori, mitte arendaja kontrolli all. Erandjuhul, kui edastatav informatsioon ei sisalda konfidentsiaalseid andmeid ega isikuandmeid, on lubatud andmete edastamine krüpteerimata kujul, kuid viisil, mis võimaldab andmete vastu võtjal veenduda saadetise tervikluses st. allkirjastatult või ajatembeldatult (X-tee turvaserveri seadistuse edastamise näide).

Vastavalt rakenduse olemusele ja riskianalüüsile rakendada meetmed OWASP ohuedetabelites (Top 10) jm tekstides antud soovituste järgimiseks.

vt OWASP ja OWASP Application Security Verification Standard (ASVS).

Kaitsta seansiküpsiseid (secure ja http only parameetrid).

Rakendada päringuvõltsimise (CSRF) vastast kaitset.

Sisendite kontroll nii front- kui ka backend-is.

Olulised sisendid tuleb kontrollida (puhastada) (ka) serveri poolel.

Veebirakendustes määratleda ja rakendada sisuturbepoliitika.

Vt Content Security Policy (CSP).

Eraldipaigaldatavate komponentide vahelistel liidestel peab olema TLS võimekus (vastastikune autentimine sertide abil). Vastavad konfigureerimisjuhised peavad sisalduma rakenduse paigaldusjuhendis.

Minimaalne võrgupääs.

Infosüsteemi komponentide pääs avalikku võrku peab olema reguleeritud vähima juurdepääsu printsiibil - infosüsteem tohib pääseda ainult sinna, kuhu pääs on teenuse toimimiseks hädavajalik. Pääsukontroll peaks eelistatult toimima dünaamiliselt ning toetama automatiseerimisvahendeid. Standardlahendusena tuleb eelistada pääsukontrolli välisvõrku rakendusest sõltumatult toimiva lüüsi abil.

Krüptograafiliste algoritmide ja meetodite valimisel lähtuda kehtivast RIA tellitud krüptograafiliste algoritmide elutsükli uuringust.

Krüptoalgoritme peab olema võimalik väikeste muudatustega vahetada

Võtmete kaitsele tähelepanu!

Juhtida tähelepanu ja rakendada meetmeid vältimaks võtmete lubamatut avalikukstulekut. Näiteid ohupraktikatest (mitteammendav loetelu): 1) võtme hoidmine versioonihalduse (git) all olevas koodirepos -> oht: push-takse avalikusse reposse -> kaitsemeede: .gitignore või võtmete hoidmine üldse eraldi; 2) võtmete seisundi ja omaduste ebaselgus -> võtmete segiminek, sellest tulenev kompromiteerumine või kaitse langus -> kaitsemeede: läbimõeldud võtmehalduse protseduur; 3) näite-seadistusfailides ei markeerita näitevõtmeid -> oht: näitevõtmed jõuavad toodangusse. Võtmeid tuleb reeglina kaitsta juba test- ja arenduskeskkondades. Ligipääs võtmetele korraldada teadmisvajaduse (need to know) põhimõttel. Võtmed, mida enam ei vajata, koheselt hävitada. Kirjandus: NIST SP-800-57 Key Management Guidelines; European Payments Council (2017) Guidelines on cryptographic algorithms usage and key management.

Rakendustes tuleb tagada isikuandmete kaitse nõuded.

Eriti isiku õigus olla unustatud ja meie kohustus seejärel kustutada kõik isikuandmed, mida me ei vaja tööks või mida me ei pea seaduse alusel töötlema. Vt isikuandmete kaitse üldmäärus. Samuti peame alati olema valmis vastama isiku nõudmisele välja anda IKS § 24 sätestatud teave.

Rakendus ei tohi kasutada RIA taristu väliseid kasutaja tegevust analüüsivaid teenuseid (nt Google Analytics).

Andmekaitse ja turvalisuse kaalutlustel.

Rakendus peab sirvikusse laaduma kiiresti.

Sirvikuühendusi tuleb efektiivselt kasutada. Vajadusel kasutada laadimisaja optimeerimistehnikaid (pakkimine, minimeerimine, profileerimine jm).

Kõrgkäideldavuse võimekus. Kui ei lepita kokku eraldi, peab iga eraldipaigaldatav tarkvarakomponent olema paigaldatav mitmes eksemplaris.

Kõrgkäideldavate rakenduste puhul tuleb seansihalduse lahendus kokku leppida kohe arendusprojekti algul. Seansi hoidmine jagatud failisüsteemis (nt. NFS) ei ole lubatud.

Süsteemi iga eraldi paigaldatav osa peab väljastama RIA monitooringusüsteemile (näiteks aadressilt heartbeat.json) masinloetaval kujul oma nime ja versiooninumbri, oluliste väliste süsteemide oleku, viimase käivitamise aja, pakendamise aja ning serveriaja.