Hankeleping nr 3-9/4515-6

Lepingu osa viitenumber 273311 004 002 000

Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu

mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja

Wizon OÜ (edaspidi täitja), registrikood 12570796, aadress Harju maakond, Tallinn, Kesklinna

linnaosa, Rotermanni tn 8, 10111, keda esindab põhikirja alusel juhatuse liige Marko Tammsaar,

edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/4515-1 alusel käesoleva

hankelepingu (edaspidi leping) alljärgnevas:

1. Lepingu ese

1.1. Lepingu esemeks on riigihanke „Tervisekassa andmelao ("STEEL") jätkuarendused ja

hooldustööd“ alusdokumentides (minikonkursi viitenumber 307718) olevas tehnilises

kirjelduses nimetatud arendustööd (edaspidi tööd).

1.2. Lepingu tööde maksimaalne maht on 500 000 eurot käibemaksuta.

1.3. Lepingut rahastatakse projektist Sotsiaalministeeriumi valdkondlik digipööre“ (SFOS: 2021-

2027.1.02.23-0007) ja/või riigieelarvest.

2. Töö üleandmise ja vastuvõtmise tingimused

2.1. Täitja annab töö üle igakuiselt alates lepingu sõlmimisest.

2.2. Töötunni põhise lepingu korral esitab täitja eelmise kuu töötundide ajaaruande, mis sisaldab

teostatud töötunde ja nende jooksul teostatud töid. Ajaaruanne esitatakse allkirjastatult

hiljemalt järgmise kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos aktiga.

2.3. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu tehnilises kirjelduses

kokkulepitud tingimustele.

2.4. Tellija vaatab töö üle vastavalt raamlepingu tingimustele.

2.5. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused

vastavalt raamlepingus kirjeldatule.

2.6. Töö teostamise tähtaeg on 24 kuud alates lepingu sõlmimisest. Leping jõustub sõlmimise

hetkel ja kehtib kuni 25 kuud või kuni poolte poolt oma kohustuste täitmiseni.

3. Lepingu hind

3.1. Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel

tellitud ja teostatud töötundide eest.

3.2. Ühe töötunni maksumuseks lepingu täitmisel on 60 (kuuskümmend) eurot käibemaksuta.

3.3. Täitja esitab tellijale e-arve igakuiselt. Arvel tuleb märkida riigihanke nimetus, lepingu osa

viitenumber, lepingu number ja kontaktisiku andmed.

3. Poolte vahelised teated ja kontaktisikud

3.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist.

3.2. Tellija kontaktisikuks lepingu täitmisel on Sten Martmaa, tel 5333 8534, e-post

[email protected] või tema asendaja.

3.3. Täitja kontaktisikuks lepingu täitmisel on Andres Kukk, tel 513 4481, e-post

[email protected] või tema asendaja.

4. Lõppsätted

4.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja lõppeb poolte poolt oma

lepinguliste kohustuste täitmisega.

4.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu

muudatustest ja pakkumusest.

4.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid:

4.3.1. Lisa 1 - Tehniline kirjeldus ühes selle lisadega;

4.3.2. Lisa 2 – Kodukord;

4.3.3. Lisa 3 – Isikuandmete töötlemise tingimused;

4.3.4. Lisa 4 – Tööde üleandmise ja vastuvõtmise akt;

4.3.5. Lisa 5 – Pakkumus (ei allkirjastata koos lepinguga).

5. Poolte allkirjad

Tellija: Täitja:

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

Tehniline kirjeldus

Tervisekassa andmelao ("STEEL") jätkuarendused ja hooldustööd

1. Mõisted ja lühendid

See peatükk loob ülevaate käesolevas hankedokumentatsioonis ja tööde käigus enim kasutusel

olevatest mõistetest ja lühenditest ning selgitab nende tähendused.

TEHIK Tervise ja Heaolu Infosüsteemide Keskus

STEEL Tervisekassa andmeladu

Andmeladu / Andmeait Andmeladu on struktureeritud kogum

integreeritud, kindlale teemale suunatud,

püsiva loomuga ja ajast sõltuvaid andmeid,

mille ülesandeks on toetada otsuste tegemist.

ODS kiht Andmelaos olev kiht (schema, dbspace või muu

andmelao platvormist tulenev objekt), kuhu

kantakse alliksüsteemist andmed sellisel kujul

nagu need alliksüsteemis on.

EDW kiht Andmelaos olev kiht (schema, dbspace või muu

andmelao platvormist tulenev objekt), mis

luuakse vajadusel integratsiooni,

andmemudeldamise ja transformatsiooni

jaoks.

DWH kiht Andmelaos olev presentatsiooni kiht (schema,

dbspace või muu andmelao platvormist tulenev

objekt) kuhu luuakse analüütikute töö aluseks

olevad tabelid inimkeelsete nimedega ja

arusaadavate seostega.

Andmed võetakse ODS kihist või EDW kihist

(vastavalt alusandmestikele) ja viiakse

optimaalsele kujule aruannete kokkupaneku

lihtsustamiseks ja päringute kiiruste

optimeerimiseks .

Analüütikakeskkond / analüütikarakendus Analüütikakeskkond on presentatsiooni kihil

töötav visuaalsete aruannete loomise

rakendus, mis toetab äriliste otsuste tegemist

ning mille sisendiks on andmelaos ja muudes

andmeallikates olevad andmed.

Andmete esitlus on visuaalne ja/või

masinloetav.

Tarkvara Tarkvara tähistab baastarkvara või

tarkvaraplatvormi (näiteks Pentaho, Apache

Hop, Vertica, Tableau jms andmeladudega

seotud tarkvara).

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

Töödekuhi Töödekuhi ehk backlog on tööde / vigade

halduskeskkonnas olev nimekiri töökäskudest.

Tööde / Vigade halduskeskkond Tööde ja vigade halduskeskkond on tellija

keskkonnas asuv rakendus vigade ja arenduste

haldamiseks kasutusel olev programm (nt. Jira).

Dokumentide halduskeskkond Dokumentide halduskeskkond on tellija

keskkonnas asuv rakendus dokumentide ja

informatsiooni (nt. spetsifikatsioonid, juhendid,

koosolekute memod) haldamiseks kasutusel

olev programm (nt. Confluence).

Reageerimisaeg Reageerimisaeg on aeg, mis on täitjal tellija

päringule vastamiseks.

Teenindusaeg / tööaeg Teenindusaeg ehk tööaeg on vastavalt

arendustööde tingimustele SLA (arendustööde

tingimused / rakenduste teenustasemed)

tabelis sätestatud teenindusaegadele.

Muu aeg on tööväline aeg.

Lahendusaeg Lahendusaeg tähendab perioodi tellimuse

saamisest kuni tööde valmimiseni, mille jooksul

täitja on kohustatud teostama kõik tööd (sh.

arendustöö, jooksva arendustöö, veaparanduse

ning täitma garantiist tulevad kohustused)

vastavalt lahendusaja tabelile ja SLA

(arendustööde tingimused / rakenduste

teenustasemed) tabelile.

Tarne Tarne on hankelepingu alusel teostatud tööde

paketina üleandmine, mis on toodangusse

paigaldamiseks korrektselt konfigureeritud ja

koodihalduskeskkonda lisatud. Täitja lisab

tarne kirjelduse ja spetsifikatsiooni

dokumendihalduskeskkonda. Täitja esitab

tarne kohta tarneteatise, lisades tarnega

seotud testimise juhendi ja vastavalt

hankelepingule automaattestid. Tarneteatise

vormi kehtestab tellija hankelepingu täitmise

käigus.

Paigalduslogi Paigalduslogi on informatsioon rakenduste

igasuguste muudatuste (nt. tarnete

paigaldamise) kohta kirjalikku taas-esitamist

võimaldavas vormis.

RL Raamleping

TK Tehniline kirjeldus

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

2. Üldine

2.1. Hanke eesmärk on sõlmida hankeleping ja hooldusleping (SLA) pakkujaga, kes hakkab

teostama Tervisekassa andmelao ("STEEL") arendus- ja hooldustöid.

2.1.1. Hanke võitva pakkujaga sõlmitakse 2 lepingut:

2.1.1.1. Hankeleping

2.1.1.2. Hooldustööde leping (SLA)

2.1.2. Olemuselt on mõlemad lepingud seotud ühe ja sama esemega.

2.2. Tööde skoop sisaldab:

2.2.1. Juba liidestunud süsteemidest täiendavate andmete ODS‑kihti kandmise

arendus: olemasolevatest Tervisekassa SAP‑süsteemidest (RERP, HERP, CRM)

uute andmehulkade tuvastamine, analüüs, ODS‑struktuuride loomine või

täiendamine, laadimiste arendus ja testimine.

2.2.2. Arendustööd uute andmeallikate liidestamiseks andmelaoga ja andmete

ODS‑kihti toomiseks: analüüsi käigus määratletavate uute süsteemide (näiteks

Ravimiskeem, Ravimiregister, MEDRE jt) ODS‑mudeli loomine, laadimiste

arendus ja valideerimine.

2.2.3. Analüüsitööd ja arendused olemasolevate andmete kandmiseks ODS-kihist

EDW kihti: EDW kihti loodavate tabelite struktuuri, andmevajaduste ja

transformatsioonide analüüs. Andmeallikate ja ärinõuete põhjal

andmemudelite koostamine ning olemasolevate mudelite täiendamine. ODS

→ EDW andmelaadimiste disain, arendus ja testimine.

2.2.4. EDW‑andmetest tuletatud presentatsioonikihi (DWH) tabelite ja vaadete

loomine ja laadimiste arendamine vastavalt analüütiliste kasutusjuhtude

vajadustele. DWH‑struktuuride täiendamine ja optimeerimine tööpiletites

täpsustatud ulatuses.

2.2.5. Arendus- ja hooldustööd andmete ettevalmistamiseks automaatseks ja

regulaarseks väljastamiseks andmelaost (sh üle x-tee).

2.2.6. Dokumentatsiooni koostamine: loodud töövoogude,

transformatsioonireeglite, mudelite ja konfiguratsioonide dokumenteerimine

vastavalt TEHIK arendusjuhenditele ja olemasoleva dokumentatsiooni

täiendamine vastavalt tehtud täiendustele.

2.2.7. Hooldustööd ja SLA‑järgne tugi: olemasolevate ODS‑, EDW‑ ja DWH-kihi

töövoogude hooldus, parandused, väiksemad arendus- ja täiendusülesanded

ning töövoogude toimimise jälgimine vastavalt SLA‑le.

2.2.8. Kõik käesolevas tehnilises kirjelduses (TK) punktis 5.1 nimetatud tööd.

3. Hanke eseme tutvustus

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

3.1. Hanke esemeks on Tervisekassa andmelao (“STEEL”) analüüsi-, arendus- ja

hooldustööd, mis on vajalikud andmelao kasutuselevõtuks, uute andmeallikate

liidestamiseks ning ODS‑, EDW‑ ja DWH-kihtide täiendamiseks. Tööde tulemusel

peavad olema tagatud uute ja olemasolevate andmete korrektne laadimine,

transformatsioonid ja esitamine Tervisekassa ärivajaduste tarbeks.

3.2. Arhitektuurijoonised leiab käesoleva dokumendi Lisadest (Lisa 1.4 - TERK STEEL

andmeplatformi arhitektuurne lahendus ning tehniline teostus_README)

3.3. Põhilised märksõnad kasutusel olevate standardite, tehnoloogiate ja teekide osas on X-

tee; HL7; CDA; FHIR; JSON; Vertica; Apache Hop; Power BI; DBT; CI/CD; Kestra;

Liquibase; Oracle; Postgre; SAP HANA; MS SQL.

4. Töö tehnilised nõuded

4.1. Rakenduste tehniline kirjeldus ja nõuded on dokumenteeritud käesolevas dokumendis ja

selle lisades.

4.2. Tööd teostatakse arvestades tellija poolt esitatud dokumenteerimise nõudeid „TEHIK

nõuded infosüsteemi dokumentatsioonile“ ja täiendavaid materjale asukohaga

https://www.tehik.ee/arendusjuhendid (vt. ka „Tööde piirangud“).

5. Tööde teostamine

5.1. Töödeks on arendus- ja veaparandus/hooldustööd, mille hulka kuuluvad raamlepingus

käsitletud tehnoloogiad ja tööd:

5.1.1. analüüsitööd;

5.1.2. arhitektuuritööd;

5.1.3. arendusressurss (Bodylease);

5.1.4. programmeerimistööd;

5.1.5. testimistööd (end-to-end automaatestimine);

5.1.6. juurutustööd;

5.1.7. koolitused;

5.1.8. konsultatsioon;

5.1.9. dokumentatsiooni koostamine;

5.1.10. jooksvate muudatusvajaduste realiseerimine;

5.1.11. veaparandustööd;

5.1.12. hooldustööd;

5.1.13. Dev-ops CI/CD.

5.2. Täitja teostab tööd kahes (2) etapis:

5.2.1. I etapp:

5.2.1.1. STEEL jätkuarendused

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

5.2.1.2. I etapi tööde tulemiks on:

5.2.1.2.1. EDW kihi analüüs:

5.2.1.2.1.1. EDW‑kihti vajalike tabelite ja struktuuride analüüs

vastavalt ärilistele vajadustele,

5.2.1.2.1.2. Transformatsioonireeglite ja loogiliste seoste

kirjeldamine ODS‑kihist EDW‑kihti kandmiseks.

5.2.1.2.1.3. Loogilise, kontseptuaalse ja füüsilise mudeli täiendamine

ning uute mudelielementide loomine.

5.2.1.2.1.4. Analüüsi käigus tuvastatud uute andmeallikate sobivuse

hindamine ja kasutamise põhimõtete kirjeldamine

EDW‑kihis.

5.2.1.2.2. EDW kihi arendus:

5.2.1.2.2.1. EDW‑ tabelite loomine ja olemasolevate tabelite

täiendamine analüüsi tulemustele vastavalt.

5.2.1.2.2.2. Andmete ODS → EDW laadimiste disain, arendus ja

testimine.

5.2.1.2.2.3. Transformatsioonireeglite realiseerimine ja

optimeerimine.

5.2.1.2.2.4. EDW‑kihti vajalike tehniliste konfiguratsioonide loomine

(töövood, laadimisskriptid, kontrollreeglid).

5.2.1.2.3. DWH kihi arendus

5.2.1.2.3.1. EDW‑andmetest tuletatud presentatsioonikihi (DWH)

tabelite ja vaadete loomine ja laadimiste arendamine

vastavalt analüütiliste kasutusjuhtude vajadustele.

5.2.1.2.4. Uute andmete toomine ODS-kihti:

5.2.1.2.4.1. Uute andmeallikate (nt Ravimiskeem, Ravimiregister,

MEDRE jt) analüüs, ODS‑mudeli loomine ja laadimiste

arendus.

5.2.1.2.4.2. Täiendavate andmehulkade toomine olemasolevatest

Tervisekassa SAP‑ süsteemidest (RERP, HERP, CRM) ja

nende integreerimine ODS‑kihti.

5.2.1.2.4.3. ODS‑ tabelite struktuuride loomine või täiendamine

vastavalt uute andmete vajadustele.

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

5.2.1.2.5. Teha andmekvaliteedi kontrollid ja testid:

5.2.1.2.5.1. Andmehulkade vastavuse kontroll (kirjete arvud,

struktuurid, väljade kvaliteet).

5.2.1.2.5.2. Transformatsioonireeglite ja ärireeglite järgimise

esmane valideerimine ODS‑ ja EDW‑ tasandil.

5.2.1.2.5.3. Monitooringu jaoks oluliste andmelaadimiskontrollide

loomine.

5.2.2. II etapp:

5.2.2.1. STEEL arendus- ja hooldustööd (SLA)

5.2.2.1.1. Tavapärasteks tööülesanneteks on seotud keskkondades

tekkivate veaolukordade analüüsimine ja parandamine ning

arendusvajaduste realiseerimine nt uute laadimiste loomine ja

olemasolevate laadimiste muutmine ja konfigureerimine sh ka

võimalikud migratsioonid erinevate süsteemide vahel, mille

eesmärgiks on äritellija analüütika/aruandluse vajaduste

rahuldamine.

5.2.2.2. II etapi tööde tulemiks on:

5.2.2.2.1. Väikearendus- ja hooldustööd, mis tagaksid turvalisuse,

tehnilise optimeerituse, töökindluse ja edasise haldus- ning

edasiarendussuutlikkuse.

5.3. Tööde teostamisel peab arvestama, et:

5.3.1. Tööd teostatakse vastavalt TEHIKu arenduskeskkondade tehnilistele nõuetele

ja arendusjuhenditele.

5.3.2. Kõik loodud töövood, konfiguratsioonid, mudelid ja muud arenduse tulemid

peavad olema dokumenteeritud.

5.3.3. Andmelao kihid (ODS, EDW, DWH) peavad säilitama struktuurse ja semantilise

järjepidevuse.

5.3.4. Uute andmeallikate liidestamisel tuleb arvestada võimalikku andmekvaliteedi

varieeruvust ning tagada ühtsed laadimis- ja transformatsioonipõhimõtted.

5.4. Konkreetsed funktsionaalsed nõuded täpsustatakse arendustööde käigus loodavates

piletites.

5.5. Tellija tagab tööde teostamiseks ligipääsu vajalikele keskkondadele ja vajadusel

omapoolse abi. Ligipääsu tehnilised tingimused jms täpsustatakse tööde teostamise

käigus.

5.6. Hankelepingu täitmise tulemina peab pakkuja andma tellijale üle:

5.6.1. Tööde jooksul tekkivate tellimuste alusel teostatud tööd vastavalt tellimuses,

käesolevas tehnilises kirjelduses ja selle lisades toodud skoobile.

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

5.6.2. Teostatud tööde dokumentatsioon (sh kasutusjuhend).

6. Meeskond

6.1. Käesolevaks tööks peab pakkuja esitama meeskonna, mis koosneb minimaalselt

järgnevatest rollidest:

6.1.1. Projektijuht

6.1.2. Analüütik

6.1.3. Arhitekt/vanemarendaja

6.1.4. Süsteemiarhitekt

6.1.5. Arendaja

6.2. Kõik raamlepingus esitatud meeskonnaliikmed tuleb esitada hankega kaasas oleva

meeskonna vormil või uue meeskonnaliikme lisamise korral lisaks ka raamlepingu (RL)

meeskonna vormil.

6.2.1. Uue meeskonnaliikme lisamiseks tuleb täita RL meeskonna vormis plokis 2

individuaalse kogemuse andmed: "2. Individuaalsed nõuded kogu pakkuja

meeskonnale (nõuded tuleb täita iga esitatud meeskonna liikme poolt

individuaalselt)"

6.2.2. Uus meeskonnaliige peab omama vähemalt ühte kompetentsi/kogemust

ühiste nõuete plokist ja see tuleb tõendada RL meeskonna vormis vastavas

plokis andmed täites: "3. Ühised nõuded kogu pakkuja meeskonnale (nõuded

tuleb täita esitatud meeskonna peale kokku)".

6.3. Pakkuja peab esitama lepingu sõlmimiseks isikuliselt vähemalt 5 meeskonnaliiget

eelnevalt defineeritud rollidesse.

6.3.1. Rolle ei ole lubatud katta (st sama isik, ei tohi olla esitatud mitmes erinevas

rollis).

6.3.2. Samasse rolli (näiteks mitme arendaja puhul) ei saa määrata sama isikut.

6.3.3. Hankelepingu kehtivuse perioodil võib vastavalt vajadusele tellijaga eelnevalt

kooskõlastades RL punkt 5.2 alusel meeskonda uusi täiendavaid nõuetele

vastavaid liikmeid juurde lisada käesolevas tehnilises kirjelduses punktis 6.2

kirjeldatud viisil.

6.4. Pakkuja peab tagama, et pakutud meeskonna koosseis on tööde teostamiseks tellija

jaoks kogu hanke perioodil täis töömahus olemas.

6.4.1. Hankijal ei ole kohustust tagada täismahus kõigi meeskonnaliikmete hõivatust,

kuid pakkujal peab olema valmidus pakkuda eelpool kirjeldatud mahus

meeskonda kogu hanke perioodil tellitavate tööde teostamiseks.

7. Mahud ja ajakava

7.1. Tööde teostamise ajad (etappide korral ka etapid) ja lepingute kehtivusajad on

sätestatud hankelepingus.

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

7.1.1. Täitja teostab tööd vastavalt hankelepingus toodud tähtaegadele.

7.1.2. Kui etappidele pole lepingu kehtivuse kuupäevadega seatud omavahelist

järjestikust sõltuvust, siis võivad etapid ka osaliselt või täielikult kattuda ning

toimuda paralleelselt.

7.2. Projekti eelduslik töömaht kokku on ~ 10 000 tundi.

7.2.1. Eelduslik töömaht arendus- ja hooldustööde lepingute vahel jaguneb

järgmiselt:

7.2.1.1. Hankelepingu maksimaalne maht kuni 500 000 EUR eeldusliku

töömahuga ~8000 tundi.

7.2.1.2. Hooldustööde lepingu maksimaalne maht kuni 150 000 EUR eeldusliku

töömahuga ~2000 tundi.

7.3. Projekti eelduslikud töömahud rollide lõikes:

7.3.1. Projektijuht: ca 500 h.

7.3.2. Analüütik: ca 3000 h.

7.3.3. Arhitekt/vanemarendaja: ca 2000 h.

7.3.4. Süsteemiarhitekt: ca 500 h.

7.3.5. Arendaja: ca 4000 h.

7.4. Projekti eelduslikud töömahud etappide lõikes:

7.4.1. I etapp (STEEL jätkuarendused): kuni 8000 h.

7.4.2. II etapp (STEEL arendus- ja hooldustööd) (SLA): kuni 2000 h.

7.5. Kõik eelduslikud töömahud on hankija eelduslikud arvutused muuhulgas hanke

eeldatava maksumuse määramiseks.

7.5.1. Märgitud töömahud ei ole hankes siduvad.

7.5.2. Hankijal ei ole kohustust nimetatud töömahtude väljaostmiseks.

7.5.3. Eelduslike töömahtude puhul arvestatakse kogumahtu ning reaalne mahtude

jaotumine rollide lõikes selgub tööde käigus.

8. Tööde aruandlus, testimine ja vastuvõtmine

8.1. Tehnilises kirjelduses ja selle lisades kirjeldatud tulemite ära toomiseks teostatakse tööd

tellija poolt sätestatud prioriteetidest lähtuvalt.

8.2. Tööde teostamiseks kasutatakse SCRUM arendusmetoodikat. SCRUMi tseremooniad ja

nende sagedus lepitakse kokku avakoosolekul.

8.3. Nii arendustööde kui ka hooldus- ja veaparandustööde tellimise, teostamise ja

vastuvõtmise täpsem protsess koos nõuetega on kirjeldatud raamlepingus (RL punkt 7),

raamlepingu tehnilises kirjelduses (RL TK punkt 5) kui ka projekti kodukorras.

9. Teenustasemed (SLA)

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

9.1. Maksimaalsed reageerimis- ja lahendusajad, mille jooksul peavad infosüsteemi, tarkvara

või rakenduse vead saama hoolduse käigus lahendatud on toodud alljärgnevas tabelis[1]:

Ärikriitilisus Kategooria Kirjeldus Reageerimisaeg Lahendusaeg

Kõrge (kriitiline

viga)

A Lahenduse

kasutamine on

tõsiselt häiritud,

alternatiivset

lahendust ei ole

võimalik

kasutada

1 tund 8 tundi

Keskmine (häiriv

viga)

B Lahenduse

kasutamine on

häiritud, kuid

alternatiivne

lahendus

võimaldab tööga

jätkata.

1 tööpäev 16 tundi

Madal (pisiviga) C Lahenduse

kasutamine ei ole

häiritud, vea

ilmnemine ei

takista otseselt

lahenduse

kasutamist

2 tööpäeva 40 tundi

9.2. A kategooria juhtumi lahendamine toimub alates tellija pöördumisest täitja poole

vajadusel ka tööväliselt kuni veasituatsiooni kõrvaldamiseni, juhul kui tellija kontaktisik

esitab juhtumi täitjale lahendamiseks tööajal. Pärast A kategooria hooldusjuhtumi

lahendamist on täitja kohustatud vigade halduse tarkvara kaudu teavitama tellija

kontaktisikut hooldusjuhtumi lahendamisest ning lahendamisele kulunud ajast.

9.3. B ja C kategooria hooldusjuhtumite puhul esitab täitja tellija kontaktisikule

kooskõlastamiseks hooldustööde teostamiseks vajaliku ajakava, ajalise ja rahalise mahu

viie tööpäeva jooksul alates tellija pöördumisest täitja poole. Kooskõlastamisele kuluvat

aega reageerimise ja lahendamise hulka ei loeta.

9.4. Reageerimis- ja lahendusaeg hakkab kulgema tellija poolt teate välja saatmise hetkest.

9.5. Tellija töövälisel ajal edastatud pöördumine loetakse laekunuks sellele järgneva

tööpäeva esimese tunni algusest.

9.6. Kui täitja rikub reageerimisaegadest ja/või lahendusaegadest tulenevat kohustust, siis on

tellijal õigus nõuda täitjalt leppetrahvi tasumist vastavalt raamlepingule.

10. Garantii

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

10.1. Kõigile lepingu alusel teostatud töödele rakendub garantii.

10.2. Garantiitingimused on kirjeldatud raamlepingus (RL punkt 10).

11. Tööde piirangud

11.1. Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud

tellija IT profiilis.

11.2. Tarkvara arenduse käigus tuleb lähtuda suunistest mis on kättesaadaval aadressil

https://tehik.ee/arendusjuhendid.

11.2.1. Automaattestide nõuded

11.2.2. Allkirjastamise teenused SiGa ja SiVa

11.2.3. IT-profiil

11.2.4. Mittefunktsionaalsed nõuded

11.3. Õigusruumi võimalikud piirangud võivad täpsustuda tööde käigus ja täitja peab sellega

tööde teostamise puhul arvestama. Neid piiranguid enne tööde algust täpselt öelda ei

ole võimalik. Õigusruum ei luba valimatult kõike, mis tehniliselt mugav ja need piirangud

võivad täpsustuda kogu hanke perioodil.

11.4. Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid

tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete

presenteerimiseks).

11.5. Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued

komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei

ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides

järgnevate tegevuste eest:

11.5.1. täies mahus CI/CD töövoogude koostamine;

11.5.2. rakenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning

testkeskkonda koos tellija poolse süsteemiadministraatoriga;

11.5.3. regulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt;

11.5.4. automaatsete testide koostamine vastavalt TEHIKu automaattestide

koostamise juhendile;

11.5.5. peakasutaja(te) koolitamine;

11.5.6. dokumentatsiooni koostamine;

11.5.7. funktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele

tellijaga.

11.6. Tarkvara arenduse puhul tuleb eelistada konteiner lahendusi. Esimene eelistus Apache

Hop. Kõik muud alternatiivsed variandid tuleb eelnevalt kooskõlastada TEHIK-u

arhitektiga.

11.6.1. EDW kihid luuakse DBT-ga.

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

11.7. Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke. Juhul

kui on vajadus kasutada mõnda avalikku või mingit muud teeki siis tuleb see enne

kooskõlastada tellija arhitektiga.

11.8. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga.

11.9. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega

keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul kui

täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda,

luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud.

11.10. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate

andmeladude toodangueelsetele keskkondadele.

11.11. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone,

andmeparandusfunktsioone ning aruandluskeskkondi.

11.12. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel GitLab.

11.13. Sõltuvuste repositoorium on vaikimisi tellija Artifactory.

11.14. Kubernetese halduseks on kasutusel Rancher.

11.15. Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda

https://wiki.sm.ee.

11.15.1. Tarkvara käivitamise ja kasutamise juhendid peavad lisaks olema ka GIT-is

koodi juures markdown formaadis.

11.16. Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee.

11.17. Aja logimiseks kasutatakse Tempo.

11.18. Aktsepteeritud suhtluskanaliteks on tellija MS Teams, tellija Jira/Confluence ja e-mail.

11.19. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult VPN tunneli

kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks on vajalik Eesti

ID kaart või Digi-ID.

12. Lisad

12.1. Lisa 1.1 - TEHIK mittefunktsionaalsed nõuded arendustele 19082025

12.2. Lisa 1.2 - Andmeladude olemus ja funktsioon juhis 14042023

12.3. Lisa 1.3 - IT-Profiil v3 veebidoc

12.4. Lisa 1.4 - TERK STEEL andmeplatformi arhitektuurne lahendus ning tehniline

teostus_README

Versioon: 2.3

Dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded (MFN) uutele infosüsteemidele ning nende dokumentatsioonile. Dokumenti hoiavad ajakohasena Tervise ja Heaolu Infosüsteemide Keskuse (TEHIK) arhitektid.

Dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtuda põhidokumendis kirjeldatust. Põhidokumendis viidatud TEHIKu koostatud dokumentide ja kolmandate osapoolte koostatud dokumentide erisuste puhul tuleb lähtuda TEHIKu dokumentides kirjeldatust.

Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel.

Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus võimalik.

Erandid tuleb kooskõlastada TEHIK'u vastutava arhitektiga kirjalikult taasesitataval kujul projektidokumentatsiooni juures.

Nõude nr

Nõude sisu Seletused Digiriigi CFR

Iseteenindus Veebid Karbitoode Koostamise eest vastutaja

Testimise läbi viib või kinnitab

1. Vastavus üldistele standarditele

1.1 Lahendus loomisel peab arvestama digiriigi ristfunktsionaalsed nõudeid.

Kohustus- ja ootustasemel olevad nõuded tuleb rakendada.

https://koodivaramu.eesti.ee/e-gov/cfr

Erisused tuleb kokku leppida Tellija lahenduse arhitektiga.

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

1.2 Lahenduse X-tee teenused peavad vastama nõuetele.

https://X-tee.ee/docs/live/xroad/ V V V Arendaja Testija

1.3 Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile.

Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peavad olema loodud kooskõlas hankes viidatud IT-Profiil versioonile.

V V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

1.4 Lahenduse kasutajaliides peab vastama dokumendis "Front-end arendusreeglid" kirjeldatud reeglitele.

https://tehik.ee/arendusjuhendid V V Arendaja Arhitekt

Testija

1.5 Rakendus peab olema kirjutatud arvestades selle lahenduse äriprotsesside ja andmete E-ITS ja ISKE turvaklassi nõudeid.

https://eits.ria.ee/ V V V Arendaja Turvatestija

Arhitekt

1.6 Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.2 tasemele AA.

https://www.w3.org/TR/WCAG22/

CFR selgitus: WCAG 2.2 alates 05.10.2023

#39 V V V Arendaja Testija

1.7 Veebipõhine kasutajaliides peab ühilduma täielikult standarditega HTML 5 ja CSS 3.

Valideerimiseks kasutatakse vastavaid validaatoreid:

https://validator.w3.org/

Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemas olevat HTML ja CSS versiooni.

#38 V V Arendaja Testija

1.8 Allkirjastamisel tuleb kasutada Tellija SiGA/SiVa vahendusteenust.

https://www.tehik.ee/arendusjuhendid V V Arendaja Testija

Arhitekt

1.9 Rakendus peab probleemideta läbima OWASP ASVS baasil põhineva testi.

Kui pole arenduses eraldi kokku lepitud teisiti, siis on OWASP ASVS tasemeks 2 (https://owasp.org/www- project-application-security-verification-standard/).

Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile.

Tellijapoolset turvatestimist teostab kolmas sõltumatu osapool. Selline esmane kolmanda osapoole turvatestimine tellitakse Tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui Tellija vastava nõudmise esitab.

#9

#10

V V V Arendaja Turvatestija

1.10 Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb kasutada turvalisi algoritme ja võtmepikkuseid.

Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut.

Värskeima uuringu leiab aadressilt https://www.ria.ee/amet-uudised-ja-kontakt/uudised- pressikontakt/uuringud-ja-analuusid#kruptouuringud

Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh sertifikaatide kasutuskohad.

#46 V V V Arendaja Arhitekt

Administraator

Turvatestija

1.11 Andmete edastus peab olema kaitstud kasutades krüpteeritud ning vajadusel autenditud ja autoriseeritud kanalit.

Autentimist ei ole vaja ainult avalike andmete edastamisel (nt avaandmed).

V V V Arendaja Turvatestija

Arhitekt

Autentimise mehhanism tuleb kokku leppida Tellijapoolse arhitektiga.

1.12 Infosüsteem peab kasutama serveri kellaaega.

Kõik mahakirjutatavad ja talletatavad kellaajad tuleb salvestada UTC ajatsoonis koos ajatsooni infoga.

Kasutajatele mõeldud kuvades tuleb kasutada sirviku ajatsooni. Aja esitamisel tekstikujul lähtuda standardist ISO 8601.

#51 V V V Arendaja Arhitekt

Administraator

1.13 Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude kui ka kasutajate arvu osas.

Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja toodud jõudlusnäitajatele.

V V V Arendaja Arhitekt

Testija

1.14 Rakendus peab olema tehniliselt tükeldatud vastavalt loogilisele jaotusele. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavad.

Lahenduse arhitektuuris kasutada domeenist juhitud disaini ja mikroteenuste põhimõtteid.

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

https://learn.microsoft.com/en-us/archive/msdn- magazine/2009/february/best-practice-an- introduction-to-domain-driven-design

https://microservices.io/

#21 V V Arendaja Arhitekt

1.15 Avalike e-teenuste loomisel peab arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhiseid.

https://riigikantselei.ee/valitsuslogo #36 V V V Arendaja Testija

1.16 Avalike e-teenuste loomisel peab arvestama Veera disainisüsteemiga.

https://veera.eesti.ee/

Näiteks kasutada ja laiendada E-Gov CVI projekti komponente:

https://e-gov.github.io/cvi/

#36 V V Arendaja Arhitekt

1.17 Lahenduse loomisel peab arvestama riiklikku koostoimeraamistikuga.

https://digiriik.eesti.ee/koostoimeraamistik/ V V V Arendaja Arhitekt

Administraator

1.18 Aadressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest "Aadressiandmete süsteem".

Liidestatakse Maa-ameti ADS teenusega.

Esitluskihis on lubatud liidestada In-ADS teenusega otsingu tarvis. Taustsüsteemides toimub liidestamine X-tee teenusega.

https://www.riigiteataja.ee/akt/115072023005? leiaKehtiv

#53 V V Arendaja Arhitekt

Standardija

Testija

1.19 Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit.

https://www.riigiteataja.ee/akt/12910889?leiaKehtiv

https://emtak.rik.ee/EMTAK/

#54 V V Arendaja Standardija

Testija

2. Nõuded rakenduse arhitektuurile

2.1 Rakenduse, andmebaasi ja kolmanda osapoole komponendid peavad olema sellised, mille turbe uuenduste eluea lõpp (Security Support) pole teadaolevalt vähem kui 2 aasta pärast.

Arendaja loodud lahenduse dokumentatsioonis (nt analüüs vms) peab olema välja toodud kasutatavate komponentide nimetused ja versioonid. Lubatud on kasutada ka tarkvara materjalide loendit (SBOM). Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuga, st versiooni tugi võib aeguda, kui uus versioon on välja lastud.

Jätkuarenduse puhul tuleb kaardistada eelneva arendusperioodi komponentide kaardistus. EOL komponentide kasutamisest tuleb teavitada Tellijapoolset arhitekti.

CFR selgitus: Kahjuks täna paljud komponendid vaatavad tulevikku 1.5 - 2 aastat. Võimalusel valida komponendid, mis omavad pikka elueatuge, nn LTS versioon.

#7 V V V Arendaja Arhitekt

2.2 Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril.

V V V Arendaja Administraator

2.3 Rakendusserver peab olema kõrgkäideldav ja horisontaalselt skaleeruv.

Kasutaja sessioonid ei tohi olla rakenduserveri klastri õla põhised.

V V V Arendaja Administraator

2.4 Rakendust peab saama ilma ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahel.

Lahenduses ei tohi olla sisse kompileeritud absoluutseid URI-sid.

V V V Arendaja Administraator

2.5 Rakenduse komponentide konfiguratsiooni peab olema võimalik ette anda käivitamisel. Konfiguratsiooni muudatus peab olema teostatav ilma rakendust kompileerimata.

Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (nt Log4j). Samuti on tungivalt soovituslik eraldi konfiguratsioonifailis hoida arendaja ja administraatori vastutusala parameetreid.

Infosüsteem peab olema seadistatav konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi.

V V V Arendaja Administraator

Testija

Näiteks konteinerlahenduste puhul peab kasutama keskkonnamuutuja põhiseid konfiguratsiooni parameetreid.

2.6 Rakenduse taaskäivitus, konfiguratsiooni muutmine vms peab toimuma mõistliku aja jooksul.

Tavaline käivitusaeg ei tohi ületada 30 sekundit.

Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate.

V V V Arendaja Testija

2.7 Lahenduse väliste osapoolte komponentide konfiguratsioonid peavad olema puhverdatud.

Kui rakendusel või mõnel selle komponendil on tihti kasutatav teenus ning sellel teenusel on laetav konfiguratsioon, siis tuleb:

laadida konfiguratsioon ühekordselt ja seda korduvkasutada; konfiguratsiooni automaatselt ja regulaarselt värskendada; regulaarsuse tarbeks peab saama määrata intervalli, millise aja järel või täpsed kellaajad, millal konfiguratsiooni värskendatakse; luua võimalus värskendada konfiguratsiooni käsitsi.

Näiteks:

digidoc4j teegi korral laetakse TSL nimekiri välisvõrgust puhvrisse, et vähendada koormust kolmandale osapoolele. OpenID konfiguratsioon

V V Arendaja Arhitekt

Testija

Administraator

2.8 Kõik andmed, andmebaasid, SQL skriptid, lähtekood ja rakendus peavad kasutama UTF-8 või UTF-16 kodeeringut.

#50 V V V Arendaja Administraator

Testija

2.9 Rakendusserveri failisüsteemi ei tohi salvestada midagi püsivaks kasutamiseks.

Näiteks objektide talletuseks kasutada objektide talletamise lahendust (nt MinIO).

V V Arendaja Administraator

2.10 Ühest relatsioonilise andmebaasi andmetabelist teise viitamisel tuleb kasutada väliseid võtmeid (Foreign key).

Erinevate skeemide vahelised ühendused on keelatud. Peab kasutama REST/SOAP/AMQP liidestust.

V V Arendaja Arhitekt

2.11 Kõik välised võtmed (Foreign Key) peavad olema indekseeritud.

Andmebaasis peab kasutama indekseid ja/või muid meetmeid, et nõuded rakenduse jõudlusele oleksid täidetud ka tulevikus. (ühe, kolme, viie või 10 aasta pärast – vastavalt planeeritud kasutusajale).

V V Arendaja Arhitekt

2.12 Tuleb kasutada päringumuutujaid (Parameter Binding).

SQL päringute väljakutsumisel väljastpoolt andmebaasi peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmentseerumist (When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation).

V V Arendaja Arhitekt

2.13 Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

2.14 Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest.

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

2.15 Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat:

Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus.

Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis.

Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja toodud ja tuleb peale installeerimist ära võtta. Karbitoodete puhul tuleb erisused läbi arutada Tellija arhitektiga.

Lahenduse puhul, milles kasutatakse andmebaasi versiooneerimist, tuleb kasutada mitut andmebaasi ühendust. Ennem rakenduse käivitumist teostatakse andmebaasi skeemi muudatused eraldi kasutajaga. Rakendus kasutab enda põhitööks kasutajat, kellel puudub õigus andmebaasi skeemis muudatusi teostada.

V V Arendaja Administraator

2.16 Failide hoidmise asukoht lepitakse iga kord kokku, kuid failid ja failide indeks peavad olema replikeeritavad teise asukohta.

Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht.

Näiteks objektide talletuseks kasutada objektide talletamise lahendust.

V V Arendaja Arhitekt

2.17 Peab olema miinimumini viidud vajadus, et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid.

Halduri haldustoimingud lepitakse Tellijaga kokku detailanalüüsi käigus.

V V V Arendaja Testija

2.18 Andmebaas peab toetama nii külm- kui ka kuumvaru (peegeldamist) teise asukohta.

Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "MSSQL filestream").

V V Arendaja Arhitekt

2.19 Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Diakriitiline (Accent) peab olema sisse lülitatud.

Näiteks PostgreSQL puhul et_EE. V V V Arendaja Testija

2.20 Kui infosüsteemid saadavad e-kirju, peavad nad kasutama välist e-maili serverit. Kirja saatmisel peab rakendus veenduma, et e-posti server võttis kirja vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322).

Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on muudetavad konfiguratsioonifaili kaudu.

Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info).

V V V Arendaja Administraator

2.21 Konfiguratsiooniparameetrite nimed peavad olema sisulised. Kui see ei ole

Näiteks : X_TEE_TURVASERVER, mitte XTTS või viitenumber, mitte vk_seb jne

V V Arendaja Administraator

võimalik, siis peab kõrval olema seletus. Testija

2.22 Infosüsteemides on eessüsteemid (front end; presentatsiooni kiht) ja tagasüsteemid (back end; äriloogika kiht) arhitektuuriliselt selgelt lahutatud ja eraldi paigaldatavad.

Rakenduse äriloogika tuleb realiseerida andmebaasist eraldi sõltumatus rakenduskihis.

Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem olema suuteline oma tööd jätkama taaskäivitamata.

Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi.

#23

#29

#64

V V Arendaja Arhitekt

2.23 Konfiguratsioonifailid peavad olema vastavalt rakendusserveri tüübile vaikimisi kaitstud failid/objektid.

Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess.

Arendaja peab välja tooma konfifailide listi, kui neid on mitu.

V V V Arendaja Administraator

2.24 Rakenduse failid, mida kasutaja näha ei tohi, peavad olema vaikimisi kaitstud kaustades ja ei tohi olla veebi juurkaustas.

Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, App_LocalResources, App_Themes, App_WebReferences, .git

V V V Arendaja Administraator

2.25 Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama sisuga parameetreid ei tohi konfiguratsioonis eksisteerida.

Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, dubleerimine on keelatud.

V V Arendaja Administraator

Testija

2.26 Esitluskihist ei tohi pöörduda otse andmebaasi poole.

Tuleb rakendada vähemalt 3 tasandilist arhitektuuri (three-tier architecture).

Lõppkasutaja lokaalsesse seadmesse paigaldatud tarkvara loeme esitluskihiks. Ka sellisel juhul ei tohi teha lõppkasutaja seadmest otse ühendust andmebaasi.

V V V Arendaja Administraator

2.27 Keskkonnapõhised muutujad peavad olema konfiguratsiooniparameetritega seadistatavad.

Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele.

V V V Arendaja Administraator

Testija

2.28 Eelistada tuleb tsentraalseid autentimislahendusi (nt Tellija SSO lahendus).

Kui rakendus realiseerib ise autentimist, siis peab olema võimalik piirata ebaõnnestunud logimisi ajaühiku kohta (mobiil-ID, paroolid) ühelt IP- aadressilt.

Eelistama peaks IP-aadressipõhist blokeeringut. Erandina Tellijaga kokkuleppel võib kasutada captchat või konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist muuta. Rakenduses realiseeritav autentimise lahendus peab olema põhjendatud ja omama kirjalikku taasesitatavat kokkulepet projekti dokumentatsiooni juures

#30 V V V Arendaja Arhitekt

Testija

2.29 Relatsioonilises andmebaasis võib kasutada vaid ISO/IEC 9075 standardiga kaetud funktsionaalsusi. Lisaks ei tohi kasutada ka sama standardi osas 13 kirjeldatud funktsionaalsusi.

Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine mõnele muule andmebaasiplatvormile ei ole võimalik. ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis.

V V Arendaja Arhitekt

2.30 Uniform resource identifier (URI) pikkus ei tohi ületada ühegi lahenduse poolt toetatava sirviku maksimaalset lubatud väärtust.

Harilikult on piiriks 2048 tähemärki, kuid iga lahenduse puhul tuleb seda eraldi järele uurida sõltuvalt lahenduse komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239.

V V V Arendaja Administraator

Testija

2.31 Veebiteenuseid (REST, SOAP) pakkuv rakendus peab olema üles ehitatud nii, et see toetaks teenuste versiooneerimist URL-i ja/või skeemi tasemel.

Näiteks WSDL puhul: Alajaotis definitions/types/schema:

complexType defineerimisel tuleb sellele lisada any element.

V V V Arendaja Arhitekt

2.32 Rakendus peab olema võimeline töötama koormusjaoturitega varustatud taristul.

Koormusjaoturi peal kasutatakse järjestikplaanurit (Round Robin) päringute suunamisel. Samuti võidakse teostada koormusjaoturil TLS ühenduse lahtivõtmist ja uuesti kokkupanemist (SSL offload).

V V V Arendaja Administraator

2.33 Sidusinfosüsteemide mittekättesaadavus ei tohi segada rakenduse töötamist. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse.

Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd jätkama rakendust taaskäivitamata.

Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid peab väljastama mõistliku (võimalikult lühikese) aja jooksul asjakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid.

V V V Arendaja Administraator

Testija

2.34 Automaatselt käivituvaid taustatöid peab saama käsitsi (taas)käivitada.

Vajalik juhul, kui automaatsel käivitumisel on tekkinud viga ja/või taustatöö on pooleli jäänud.

Pärast vea põhjuse korrigeerimist peab saama taustatöö uuesti käivitada.

Lahendusse on vaja luua taustatööde haldamiseks ja juhtimiseks võimekus, et võimaldada vastavates rollides olevatel inimestel lahendust hallata (nt peakasutaja või rakenduse administraator).

V V V Arendaja Testija

2.35 Kui ajastatult käivitatav taustatöö ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole

Kui lahendus töötab mitmel õlal, ei tohi tööd, mis ei ole mõeldud paralleelselt käima, käivituda korraga mitmel õlal. Peab rakendama lukustus põhimõtet.

V V Arendaja Administraator

Testija

võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud.

2.36 Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate tehnoloogiate ja standardite valik tuleb kooskõlastada Tellijapoolse arhitektiga.

V V V Arendaja Arhitekt

2.37 Rakenduse ühenduste (s.h. andmebaasi ja sidusinfosüsteemide ühendused) realiseerimisel tuleb kasutada ühenduste puulimist (connection pooling).

Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang, päringu aegumise aeg (request timeout) ja ühenduse elususe periood (keepalive). Rakenduse ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Ühenduste taastumisel peab rakendus olema suuteline oma tööd jätkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse.

V V V Arendaja Arhitekt

2.38 Rakenduse uuendustega kaasnevad andmebaasi muudatused tuleb automatiseerida ja versioneerida.

Näiteks Liquibase või Flyway. V V Arendaja Administraator

2.39 Mitterelatsioonilises mudelis andmete hoiustamine tuleb eraldi kokkuleppida.

Näiteks kui soovitakse kasutada NoSQL lahendusi püsivaks andmete talletuseks, tuleb see kokku leppida Tellijapoolse arhitektiga.

V V V Arendaja Arhitekt

2.40 Mikroteenuste arhitektuuris vältida ebavajalikku andmete dubleerimist.

Iga teenus vastutab enda valdkonna andmete eest. Kui on vajadus lisaandmete jaoks, on tal võimalik pöörduda teise teenuse poole.

V Arendaja Arhitekt

2.41 Infosüsteemide vaheline andmevahetus toimub üle X-tee.

https://www.ria.ee/riigi-infosusteem/andmevahetuse- platvormid/andmevahetuskiht-X-tee

https://www.riigiteataja.ee/akt/106082019017? leiaKehtiv

Erandiks on lubatud päringud sama andmekogu raames. Sellisel juhul tuleb turvalisus tagada lahenduse loojate poolt. Kasutada kas mTLS või tõendipõhist autentimist.

#22 V V V Arendaja Arhitekt

3. Turvalisuse tagamisega seotud nõuded

3.1 Asutusesiseseks kasutamiseks mõeldud rakenduse kasutajate autoriseerimist peab saama teha vastu TEHIKu keskset autoriseerimisteenust.

TEHIKu haldusala kasutajad ja nende rollid on kirjeldatud Active Directory's. Võimalik on kasutada rollide pärimiseks TEHIK SSO teenust.

Täpsem tehniline lahendus leida koos TEHIKu poolse arhitektiga.

V V V Arendaja Turvatestija

3.2 Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades.

V V V Arendaja Turvatestija

3.3 Rakendus tohib kasutada vaid sessiooni küpsiseid (cookies). Muude küpsiste kasutamine tuleb kokku leppida Tellijapoolse arhitektiga.

V V Arendaja Turvatestija

3.4 Kui andmebaasis olevate andmete E-ITS tervikluse (I ehk integrity) turvaosaklass on S või VS, siis tuleb kõik andmebaasi kirjed/tabelid versioneerida.

St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist informatsiooni:

viide kirjele, mille ta kehtetuks muutis (kui on) kasutaja, kes kirje lõi kirje loomise aeg sessiooni-ID (kui on olemas) X-tee ID (kui on olemas)

Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni;

kasutaja, kes kirje kehtetuks tunnistas; kirje kehtetuks tunnistamise aeg.

Täpne realisatsioon tuleb kokku leppida Tellija arhitektiga.

#55

#49

V V Arendaja Turvatestija

Arhitekt

3.5 Rakendusega peab kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei võimalda siduda konfidentsiaalset informatsiooni päris andmesubjektiga.

Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised suhted.

Täpsem vajadus ja tegevusplaan tuleb koostada Tellija arhitekti ja tooteomanikuga.

V Arendaja Arhitekt

3.6 Rakendus ja selle komponendid peavad võimaldama kasutada keskkondade lahusust.

Arendaja arendab arenduskeskkonnas ja annab tarne üle Tellijale paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas.

Üldjoones on kõik keskkonnad majutatud Tellija majutuses.

V V V Arendaja Turvatestija

3.7 Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades.

St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi.

V V V Arendaja Turvatestija

3.8 Rakendus ei tohi teostada X-tee päringut otse kasutajaarvutist.

Kasutajaarvutitest otse X-tee päringute tegemine on arvutivõrgu tasemel kinni.

V V V Arendaja Turvatestija

3.9 Veebipõhised välise veebilehega rakendused peavad kasutama vahendeid,

IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Lubamatud

V V V Administraator Turvatestija

kaitsmaks rakendust lubamatute päringute eest.

päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. Blacklistingu asemel tuleb kasutada whitelisting põhimõtet.

3.10 Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud.

Rakendus peab sisenemisel näitama pärast õnnestunud sisselogimist eelmise õnnestunud sisselogimise aega. Kui on toimunud ebaõnnestunud sisselogimise katseid, siis peab ka kuvama, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti.

Ebaõnnestunud logimiste katsete kuvamise nõue kehtib juhul, kui autentimine ja autoriseerimine lahendatakse rakenduses lokaalselt.

V V V Arendaja Turvatestija

3.11 Kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg.

Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega.

Nõue kehtib juhul, kui kasutatakse lahenduse sisest sessiooni haldust.

V V V Arendaja Turvatestija

3.12 Lahenduses kasutatavate küpsiste sisu peab olema krüpteeritud

Eesmärk on kaitsta kasutaja andmeid, mis on talletatud sirviku küpsiste hulka.

V V Arendaja Turvatestija

3.13 LDAP lahenduse (nt Active Directory) kasutamisel peab rakendus kasutama kontoga kaasnevaid piiranguparameetreid.

Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne.

#30 V V V Arendaja Turvatestija

3.14 Tagada tuleb rakenduse rollide lahusus. Peakasutajal ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest.

V V V Arendaja Turvatestija

3.15 Arendus peab olema orienteeritud toodangukeskkonnas toimimiseks.

Toodangukeskkonnas mittevajalikud funktsionaalsused peavad olema eraldi juhitavad ja tavakäivitusel väljalülitatud. Näiteks eraldiseisva profiiliga Java arenduste puhul. (kasutuseta funktsionaalsus ja komponendid, mis on mõeldud testimiseks testkeskkonnas ja arendusabiks arenduskeskkonnas)

V V V Arendaja Turvatestija

3.16 Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud ning krüptoaheldatud.

See tagab, et tõestusväärtusega andmeid ei saaks märkamatult kustutada.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

3.17 Kui rakenduses on S3 salastatuse astmega andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

3.18 Rakendus peab võimaldama hõlpsalt välja vahetada aegunud ja ebaturvalise krüptoalgoritmi.

Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada.

Lisaks peavad eksisteerima vahendid juba olemasolevate krüpteeritud andmete ümberkrüpteerimiseks.

V V V Arendaja Turvatestija

3.19 Rakenduse andmebaasi krüpteerimisega seotud andmeväljad peavad olema muudetava pikkusega.

Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme.

V V V Arendaja Turvatestija

3.20 Lahendus peab olema kaitstud HTMLi süstimiste eest.

OWASP soovitab kasutada DOMPurify lahendust HTMLi saneerimiseks

#44 V V V Arendaja Arhitekt Turvatestija

4. Logimine

4.1 Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses.

Näiteks Java raamistikku log4j, SLF4J, logback; transpordiks syslog, Elastic Beats; logi formaadiks JSON. Logi peab olema loetaval tekstilisel kujul, et logikirjeid saaks töödelda masinmõistetavalt ja inimloetavalt.

V V V Arendaja Arhitekt

Administrator

4.2 Peab kasutama logikomponenti ja peab olema võimalik juhtida logikomponendi seadistusi.

Seletus: Näiteks peab saama muuta logimise taset ja logimise formaati.

V V V Arendaja Arhitekt

Administraator

Testija

4.3 Logisündmused peavad olema loogiliselt eristatavad.

Auditlogi (Seansilogi, tegevuslogi) - info sisselogimiste, väljalogimiste ja seansi aegumiste kohta. Vigased sisselogimise katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega logimise katsed. Kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi. Tehniline logi - rakendusserveri poolt loodud logi Vealogi - erinevate veaolukordade info Silumislogi - arendajate jaoks vajalik debug info

#41 V V V Arendaja Arhitekt

Administraator

4.4 Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida, kui ei ole nõutud teisiti.

V V V Arendaja Arhitekt

Testija

4.5 Logides peab olema maksimaalselt üks sündmus ühel real.

V V Arendaja Administraator

Testija

4.6 Logikirje peab olema JSON formaadis. V V Arendaja Arhitekt Testija

4.7 Logiväljade nimed peavad olema normaliseeritud ja tuleb rakendada Elastic Common Schema spetsifikatsiooni.

Samatüübilised logiväljade nimed peavad olema ühtsed üle logi.

https://www.elastic.co/guide/en/ecs/current/ecs- reference.html

V V Arendaja Arhitekt Infoturbespetsialist

4.8 Rakendus peab logima kasutaja edukat ja ebaedukat autentimist ja sessiooni lõpetamist, kasutaja IP-d ja autentimismeetodit.

Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale juurdepääsumandaat, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui võimalik kasutajatunnus (mobiil-ID puhul telefoni number; ID- kaardi või Smart-ID puhul isikukood).

Kui rakendus kasutab kasutajate autentimiseks välist autentimise/autoriseerimise vahendit, siis leppida eraldi kokku autentimise detailsus ehk mida kajastatakse autentimise/autoriseerimise vahendis ja mida rakenduses.

V V V Arendaja Arhitekt

Testija

4.9 Üle terve logi peab olema kasutaja sessiooni käigus tehtud tegevusi või sama sündmust võimalik siduda loogiliselt kokku.

Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Selleks ei sobi kellaaeg, IP ega isikukood. Sobib näiteks unikaalne ID, mis ei tohi olla sessiooni ID, sest seda saaks logist välja lugeda ja rünnakuks ära kasutada. Võib olla sessiooni ID räsi koos transaktsiooni ID'ga.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

#17 V V V Arendaja Arhitekt

Testija

4.10 Andmete loomise/vaatamise/muutmise/kustutamise tegevused peavad olema kajastatud logides. Logida tuleb ka päringud, mille vastus on puhverdatud.

Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes?, mida?, kus?, kust?, millal?, kuidas? ja tulemus.

Konkreetne detailsus ja tehniline lahendus tuleb kokkuleppida Tellija arhitektiga. Näiteks on mõistlik luua audit teenus, mis annab vastavale rollile võimaluse näha ja auditeerida tegevusi.

V V V Arendaja Testija

Turvatestija

Infoturbespetsialist

4.11 Administraatorite ja haldurite poolt tehtavaid andmete vaatamised, muutmised sh kustutamised (ka otse baasis) tuleb logida. Muutmise puhul tuleb logida nii uus kui ka vana väärtus.

Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise, muutmise logimist ise (ka tavakasutajate logimist) deaktiveerida või logisid kustutada/muuta.

Konkreetne detailsus ja tehniline lahendus tuleb kokku leppida Tellija arhitektiga. Näiteks on mõistlik luua audit teenus, mis annab vastavale rollile võimaluse näha ja auditeerida tegevusi.

V V V Arendaja

Administraator

Infoturbespetsialist

Testija

4.12 Süsteemsed logid ei tohi sisaldada otseseid isikuandmeid.

Tulenevalt GDPRist ja logi sündmuse subjekti õigustest, ei tohi logide igapäevane analüüsimine ja jälgimine riivata sündmuse subjekti õigusi.

Näiteks kasutada kasutaja nime ja tunnuse asemel tema süsteemset ID'd. Lahendus peab sisaldama võimalust ID ümberpööramist reaalseteks andmeteks. Antud tegevus peab olema auditeeritav.

Konkreetne detailsus ja tehniline lahendus tuleb kokkuleppida Tellija arhitektiga.

V V V Arendaja Arhitekt

Testija

Turvatestija

Infoturbespetsialist

4.13 Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega.

Näiteks NULL V V Arendaja Testija

4.14 Logis tuleb kõik mittekuvatavad (non- printable) sümbolid kodeerida.

Näiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff.

V V Arendaja Testija

4.15 Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu.

Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST- parameetreid ja nende väärtusi. Logimise detailsusrežiimi (info, warning, errog, debug) peab saama muuta.

V V V Arendaja Administraator

Testija

4.16 Rakendus ei tohi X-tee päringuid salvestada rakenduse logis. Logis peab olema X-tee tunnus (ID), et saaks siduda X-tee logiga.

V V V Arendaja Administraator

Testija

4.17 Rakenduse funktsionaalsuse kirjeldusega tuleb luua logimise dokumentatsioon ja loginäidised. Koos funktsionaalsuse arendamisega tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon. Dokumentatsioon peab sisaldama logis kasutatud klassifikaatorite kirjeldusi.

Mida logitakse, kuidas sündmused on logis jagatud, logiridade näited.

V V V Arendaja Arhitekt

Administraator

Infoturbespetsialist

5. Testimine

5.1 Rakenduse kõik üleantavad versioonid peavad enne Tellijale üle andmist olema testitud.

Testitulemused tuleb edastada Tellijale koos rakenduse üleandmisega. Vaata lisaks nõuet 5.2 ja 5.3.

Testid peavad olema käivitatavad Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ning olema dokumenteeritud, kuidas teostada testide seadistamist ja manuaalset käivitamist.

#12 V V V Arendaja Testija

5.2 Lahendus peab olema minimaalselt 75% ulatuses kaetud automaatsete komponenditestidega (unit test).

Käivitatakse Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust raporteeritakse lähtekoodi analüsaatoris (nt SonarQube).

#12

#35

V Arendaja Arhitekt

Testija

5.3 Lahendus peab olema minimaalselt 50% ulatuses kaetud automaatsete

Käivitatakse Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab).

#12

#33

V Arendaja Arhitekt

Testija

vastuvõtutestidega.

5.4 Rakendusega peab olema kaasas skript jõudlustestide tegemiseks.

Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda Tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist.

Jõudlustestid peavad olema käivitatavad Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ning olema dokumenteeritud, kuidas teostada testide seadistamist ja manuaalset käivitamist.

Konkreetne detailsus ja tehniline lahendus tuleb kokku leppida Tellijapoolse testija esindajaga.

#12

#34

V V Arendaja Arhitekt

Administraator

Testija

5.5 Testimine toodangu andmetega on keelatud.

Testimiseks tuleb luua vastavad andmekooslused, et tagada tervik voo testimise võimekus.

V V Arendaja Arhitekt

Administraator

Testija

5.6 Enne lahenduse esmast tootesse lansseerimist peab olema teostatud turbetestid ja seal välja toodud probleemid lahendatud.

Turbe testide teostamist ja tellimist koordineerib Tellijapoolne testija esindaja. Samuti tuleb kokku leppida põhimõtted, millistel juhtudel turbe testi tuleb uuesti teostada.

Parendused ja lahendused tuleb kokku leppida Tellija arhitektiga.

#9

#10

V V Arendaja Arhitekt

Administraator

Testija

6. Monitooring

6.1 Rakendusel peab olema masinloetav tervise testleht (health check) JSON kujul.

Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom built rakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone reeta. Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei tööta). Rakenduse, andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb Tellija arhitektiga kokku leppida. Testleht peab oma konfiguratsiooni võtma rakenduse üldisest konfiguratsioonist (baasistring, välised ühendused).

Näiteks java Spring raamistiku puhul kasutada actuatori võimekust.

#16 V V Arendaja Arhitekt

Administraator

6.2 Rakendusel peavad olema elususe ja tööks valmiduse otspunktid.

Näiteks java Spring raamistiku puhul kasutada actuatori võimekust. Konteinerite orkestraatori kiht teostab nende järgi otsuseid. Antud lehekülgede sisuline poole peab kajastuma ka tervise testlehel.

#16 V Arendaja Arhitekt

Administraator

6.3 Rakendus peab pakkuma monitooringu lehte, kus leidub informatsioon rakenduse funktsionaalsuse toimimise kohta.

Tuleb rakendada OpenMetrics spetsifikatsiooni.

Monitooringu leht peab välja kuvama ka testlehel kuvatud komponentide olukorda.

Näiteks kui testleht kuvab infot, et andmebaasi ühendusega on probleeme, peab see kajastuma ka monitooringu lehel. Monitooringu lehte kasutame lahenduse jälgimiseks.

https://openmetrics.io/

#16 V V Arendaja Arhitekt

Administraator

7. Nõuded rakenduse lähtekoodile

7.1 Lähtekoodi kommentaarid peavad kõigis lahenduse kihtides (rakenduse enda kood, andmebaas jne) olema kirjutatud inglise keeles.

NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad lahtise koodiga koodilõigud jms.

Kui tegu on olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt.

#2 V V Arendaja Arhitekt

7.2 Lähtekoodi genereeritud dokumentatsioonid peavad olema selged, arusaadavad ja sisuliselt kirjeldama vastavat koodi, mille juures nad on. Lähtekoodist genereeritava dokumentatsiooniga tuleb katta kõik avalikud (public) meetodid ja funktsioonid.

Rakenduse kood peab olema piisavalt hästi dokumenteeritud, et erialast haridust omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama.

Rakendama peab dokumenteerimisel programmeerimiskeele parimaid praktikaid.

Näiteks tarkvara, mis on kirjutatud Java keeles, peab kasutama javadoc põhimõtteid ja võimekust.

#2 V V Arendaja Arhitekt

7.3 Muutujate, tüüpide ja funktsioonide nimed peavad olema sisulised ja andma aimu nende otstarbest.

Tuleb rakendada Clean Code põhimõtteid. Kui muutuja nimetus vajab kommentaari, siis pigem muuta muutuja nimetust kommenteerimise asemel.

Näiteks muutujate nimed peavad olema selged ja arusaadavad.

Hea näide muutujast: elapsedTimeInDays

Halb näide muutujast: etid

#2 V V Arendaja Arhitekt

7.4 Koodis kasutatavad konstandid ja lühendid tuleb kirjutada suurte tähtedega, lähtudes kasutatava programmeerimiskeele parimast praktikast.

Nt Javas identifikaator --> ID V V Arendaja Arhitekt

7.5 Koodis kasutatavaid konstante ei tohi selle kasutamise kohta väärtusena

V V Arendaja Arhitekt

hardcode'da – need tuleb defineerida muutujatena ja kasutada läbi nende.

7.6 Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms).

N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti.

V V Arendaja Arhitekt

7.7 Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad.

Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui tegu on tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID

V V Arendaja Arhitekt

7.8 Andmebaasi väljade pikkused tuleb kirjeldada sümbolites, mitte baitides.

Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of allocating x bytes of storage for the field, x chars of storage must be allocated).

V V Arendaja Arhitekt

7.9 Kui kokku pole teisiti lepitud, siis rakenduse kood peab olema kirjutatud vastavalt Google stiili juhendile.

https://google.github.io/styleguide/

Kui tarkvara keelel puuduvad Google stiili juhised, siis tuleb need kokku leppida Tellija arhitektiga enne kodeerimist.

V Arendaja Arhitekt

7.10 Koodi valideerimiseks kasutatakse minimaalselt Tellija lähtekoodi analüsaatorit.

Üleantavas koodis ei tohi olla kriitilisi ja kõrgemaid probleeme.

IT profiil: Lähtekoodi analüüs

#10

#40

V V Arendaja Arhitekt

7.11 Kasutuses mitteolev kood tuleb rakenduse lähtekoodist kõrvaldada.

Erandina on lubatud koodi osad, mis on valmis tehtud, aga ei ole veel kasutusse rakendatud ja on peidetud nn. funktsionaalsuste lippude (feature flag) taha.

V V Arendaja Arhitekt

7.12 Arendamisel kasutatakse DRY ja SOLID printsiipe.

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself http://en.wikipedia.org/wiki/SOLID_(object- oriented_design)

V V Arendaja Arhitekt

7.13 Üleantavas koodis ei tohi olla paroole, mida on kasutatud arenduse käigus.

Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga “<password>“.

#28

#63

V V Arendaja Arhitekt

7.14 Üleantavas koodis ei tohi olla komponente, mille CVSS punktid on 7 ja kõrgemad ning CVE on rakendatav.

Kui CVE ei ole lahenduses rakendatav ehk tegu on lahenduse mõistes vale-positiivsega, siis võib komponendi uuendus lükkuda edasistesse etappidesse. Eeldusel, et tegu ei ole viimase üleantava tarne versiooniga. Partneri viimane üleantav versioon peab olema turbevigade vaba.

Mõistlik on kõik CVE'd omavad komponendid uuendada või välja vahetada. Ajas võib mitme madalama punkti koosmõjul avalduda kriitiline turbeprobleem.

#10 V V Arendaja Arhitekt

7.15 Üleantava lahendusega peab olema kaasas viis SBOM genereerimiseks.

SBOM ehk tarkvara materjalide loend. Mõistlik on SBOM genereerimine viia üheks järjepideva integratsiooni voo sammuks.

SBOM publitseerimine ja analüüsimine tuleb kokku leppida Tellijapoolse arhitektiga.

https://www.sbom.com/

V V Arendaja Arhitekt

7.16 Tehniliste komponentide API'del eksisteerib automaatselt genereeritud dokumentatsioon.

Näiteks REST API'de puhul kasutada OpenAPI spetsifikatsiooni.

https://www.openapis.org/

#20 V Arendaja Arhitekt

8. Andmekvaliteet

8.1 Andmekorjel kasutatakse klassifikaatoreid ja loendeid, kus need on olemas.

Vabatekstivälju tuleb vältida. #61 V V V Arendaja Arhitekt

Testija

8.2 Tekstiväljad on mõistliku suurusega. Varchar N tähemärki, kus N on ratsionaalne kaalutlus, kui suur lahter võib olla; vältida text/long-varchar kasutust, kui see pole hädavajalik.

V V Arendaja Arhitekt

8.3 Rakendus peab automaatselt eeltäitma kõik võimalikud andmeväljad, kui need andmed on varem riigile esitatud või kui nende väärtused on võimalik automaatselt arvutada.

Välja arvatud logimisvormi lahtrid autentimisel.

Näiteks: kirje sisestamise kuupäev, kasutaja nimi, sünnikuupäev jne

V V Arendaja Testija

8.4 Lahenduses peab olema tagatud idempotentsus.

Kasutaja sama tegevuse kordamisel ei tohi tekkida lahendusse andmeid topelt.

Näiteks "salvesta" nupu korduval vajutusel ei tohi tekkida dubleeritud andmeridu.

V V Arendaja Arhitekt

Testija

8.5 Analüüsi tulemusena ja enne esimese arendusetapi algust peab infosüsteemi kohta olema koostatud kontseptuaalne andmemudel olemi-suhte diagrammi (Entity Relationship Diagram, ERD) või klassidiagrammina olemite ja nende semantika kirjeldusega: teenuse nimi ja selle ärilne kirjeldus, tabeli nimi ja selles talletatavate andmete semantika ehk äriline kirjeldus.

Peab olema dokumenteeritud projekti põhi dokumentatsiooni juures. Dokument tuleb hoida ajakohane.

#58 V Arendaja Arhitekt

8.6 Enne igat arendusetapi algust peab infosüsteemi kohta olema koostatud loogiline andmemudel ehk olemi-suhte diagramm (ERD) koos kirjeldusega: skeemi ja olemite ehk tabelite nimi ja semantika, atribuutide ehk tabeli veergude kirjeldus, sh primaar- ja välisvõtmete kirjeldus: veeru nimi, andmetüüp, kohustuslik või

Peab olema dokumenteeritud projekti põhi dokumentatsiooni juures. Dokument tuleb hoida ajakohane.

#58 V Arendaja Arhitekt

mittekohustuslik (NULL/ NOT NULL), semantika ehk andmete tähendus.

8.7 Füüsiline andmemudel peab iga iteratsiooni lõpus või tarne tähtajaks selle iteratsiooni või tarne ulatuses sisaldama lisaks ajakohasele kontseptuaalsele ja loogilisele andmemudelile ka andmekirjeldusi andmebaasis.

Igal skeemil, tabelil ja veerul on kommentaar andmekirjeldusega, mis vastab loogilise andmemudeli kirjeldusele.

#58 V Arendaja Arhitekt

9. Kasutajaliides

9.1 Kasutajaliidese kõik disainiotsused peavad olema kooskõlastatud Tellijaga enne nende realiseerimist.

V V V Arendaja Projektijuht

9.2 Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebibrauseritega, sh nutiseadmetel (Android, IOS).

Minimaalselt Microsoft Edge, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja poolt toetatud versioonid.

Täpsemad nõuded dokumendis "Front-end arendusreeglid".

V V V Arendaja Testija

9.3 Rakenduse värviskeemi ja logo kasutamine peab vastama Tellija ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG).

Kui tegemist on struktuurfondide projektiga, on lisaks nõutud ka vastav SF sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida Tellijalt.

V V Arendaja Testija

9.4 Kasutajaliidese kõik osad ja teated peavad olema eestikeelsed.

Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud hankedokumentides.

V V V Arendaja Testija

9.5 Sisemiseks kasutamiseks tehtav rakendus peab olema graafiliselt skaleeruv ja mugavalt kasutatav Tellija töökohaprofiilis loetletud resolutsioonides.

Toetatud peavad olema töökohaprofiilis loetletud resolutsioonid.

Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba.

V V Arendaja Testija

9.6 Kasutajaliideses toiminguni (põhi- ehk enamkasutatavad tegevused) navigeerimiseks peab kehtima 3 kliki printsiip, väljalogimiseks 1 kliki printsiip.

Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas.

V V Arendaja Testija

9.7 Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja massmuutmiste kohta kui just teisiti kokku pole lepitud.

V V V Arendaja Testija

9.8 Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale eestikeelse kasutajasõbraliku veateatega, mis sisaldab ka vea koodi. Veateated peavad olema hallatavad.

Veateated peavad olema sellised, mis võimaldavad IT- abil võimalikult lihtsalt tuvastada vea olemuse ja asukoha.

V V V Arendaja Testija

9.9 Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole teisiti kokku lepitud.

Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V Arendaja Testija

9.10 Rakenduse kasutajaliides peab teavitama kasutajat ette sessiooni aegumisest.

Etteteavitamise aeg peab olema konfigureeritav. V V V Arendaja Administraator

Testija

9.11 Kui vormile sisestatakse mahukaid andmevälju, peab kasutajaliides kokku lepitud ajavahemike järel salvetama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks.

Näiteks kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning salvestatakse vastava etapi lõpus.

V V Arendaja Testija

9.12 Interaktiivsete vormide puhul (näiteks faili üleslaadimine) ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada).

V V Arendaja Testija

9.13 Esilehel (sisselogimata) ja pärast kasutaja sisselogimist peab olema lihtne võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsasti lisatav ja kasutajale märgatav.

Näiteks võimalikud teavitused: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus, hetkel on hooldus, uuendage isikuandmeid jne.

Mõistlik on hooldusteate võimekiust juhtida taustteenuse abil. Näiteks läbi esitluskihi jaoks loodud seadete REST liidese.

V V Arendaja Testija

10. Dokumentatsioon

10.1 Lõppkasutajatele ja avalikkusele suunatud rakenduse dokumentatsioon peab olema kirjutatud eesti keeles.

Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud Tellija jaoks) dokumentatsioon. Samuti võib erandiks olla väliste osapooltega seotud projektid. Erandid tuleb kooskõlastada Tellijaga enne dokumentatsiooni koostamist.

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Infoturbe spetsialist

10.2 Lahendus kirjeldatakse RIHA määruse nõuete kohaselt.

https://www.riigiteataja.ee/akt/12933746? leiaKehtiv#para6

#57 V Arendaja

Projektijuht

Tellija RIHA haldur

Projektijuht

10.3 Rakenduse dokumentatsioon peab vastama dokumendis "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele.

Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas tehnliste IT baasteadmistega isik

V V Arendaja Projektijuht

Arhitekt

Administraator

suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi).

Täpsemad nõuded dokumendis "Nõuded infosüsteemi dokumentatsioonile".

Testija

Infoturbe spetsialist

10.4 Rakenduse dokumentatsioon peab sisaldama tabelite-andmete-logide mahu kasvu arvestuslikku hinnangut rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas).

Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel- ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu.

V V Arendaja Projektijuht

Arhitekt

Administraator

Infoturbe spetsialist

10.5 Iga uue versiooniga peab alati välja tooma versiooni muudatuse kirjeldused (release notes).

Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel.

V V V Arendaja Projektijuht

10.6 Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh TLS sertifikaatide kasutuskohad.

V V Aremdaja Arhitekt

Administraator

11. Versioonihaldus

11.1 Kogu rakenduse testimiseks, koolituseks või implementeerimiseks üle antav lähtekood ja tarkvarapaketid peavad olema versioneeritud. Kasutama peab Tellija versioonihalduse ja tehiste (artifaktide) repositooriumi.

Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.

#1 V V Arendaja Arhitekt

Administraator

11.2 Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi.

Hea tava on, et paralleelse arendamise puhul võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist.

V V Arendaja Arhitekt

Administraator

11.3 Nii arendamisel kui ka hoolduslepingute korral kasutatakse Tellija tööde ja veahalduse keskkonda.

Arendajale antakse selleks õigused Tellija tööde ja veahalduse keskkonda.

Veahalduse keskkonda juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.

V V Arendaja Projektijuht

11.4 Versioonihaldusesse muudatuste üleslaadimisel kasutada üleslaadimissõnumis Conventional Commits stiili.

https://www.conventionalcommits.org/ V Arendaja Arhitekt

12. Paigalduspaketi kooste

12.1 Rakendus on versioneeritud kasutades semantilise versioneerimise põhimõtet.

A.B.C kujul, kus C on veaparandus, B on funktsionaalne uuendus, mis töötab ka vanematel integratsioonidel ja A on integratsioone potentsiaalselt lõhkuv uuendus.

Versiooni suurt numbrit A kasutatakse ka API versiooni defineerimiseks.

Lisasoovitus: Kui major versioon saab uuenduse, siis peavad vanema versiooniga teenused hakkama tagastama päises teavitust, et versioon on deprecated (nt. X-API-Deprecated).

https://semver.org/

#15 V Arendaja Arhitekt

Administraator

12.2 Juhul kui versioonihalduse keskkond ei paku paigalduspaketile kontrollsumma (checksum) automaatset koostamist, siis koostatakse kontrollsumma arendaja poolt ja pannakse eraldi .sum failina tarnele kaasa.

Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum.

V V Arendaja Administraator

12.3 Tarnitava lahenduse koosseisus üleantava lähtekoodiga peavad kaasas olema kirjeldused sellest paigalduspaketi koosteks.

Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mistahes muu moodus paigalduspaketi tekitamiseks.

Eelistatud on kasutada Dockerfile ja Gitlab töövooge.

V V Arendaja Projektijuht

Administraator

12.4 Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult minimaalse rakenduse käitamiseks vajamineva failikomplekti.

Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik rakenduse käitamiseks.

V V Arendaja Arhitekt

Administraator

12.5 Kooste kirjelduste alusel valmivat paigalduspaketti peab olema võimalik liigutada erinevate masinate vahel.

Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb see tingimata just sealsamas kokku kompileerida.

V V Arendaja Administraator

12.6 Rakenduse kõik sõltuvused peavad olema kompileerimisel saadavad Tellija tehiste repositooriumist.

#4 V V Arendaja Arhitekt

12.7 Andmebaasi paigalduse skriptid ei tohi olla kompileeritud.

Administraator tahab veenduda skripti sisus. V V Arendaja Administraator

12.8 Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse keskkonnast sõltumatult (konteinerlahenduses) kokku kompileerimiseks.

Tellijal peab olema võimalik suuri pingutusi tegemata ja keskkonna erinevusi vältides teha rakendusest paigaldatav pakk.

V V Arendaja Arhitekt

12.9 Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse lokaalselt

Vajadusel peab konteinerlahendus käivitama ka rakenduse muud sõltuvused (näiteks andmebaas).

V V Arendaja Arhitekt

mõnes konteinerlahenduses (Docker) käivitamiseks.

See on Täitjale uue meeskonnaliikme liitumise lihtsustamiseks ja Tellijale võimalus suuri pingutusi tegemata süsteemi testimiseks.

12.10 Paigalduspakett koostatakse Tellija pideva integratsiooni (continuous integration - CI) ja paigaldus (continuous deploy - CD) arendus keskkonnas.

#13 V V Arendaja Arhitekt

12.11 Kubernetesel (K8s) orkestreeritavate lahenduste paigalduste jaoks tuleb luua Helm chart.

https://helm.sh/

Helmi jaoks kasutatava malli annab Tellijapoolne arhitekt.

V V Arendaja

Arhitekt

Arhitekt

Administraator

12.12 Kubernetesel (K8s) orkestreeritavate lahenduste paigalduste jaoks tuleb luua vajalikud automaatsed laienemise reeglid.

https://kubernetes.io/docs/tasks/run- application/horizontal-pod-autoscale/

V V Arendaja

Arhitekt

Arhitekt

Administraator

1 / 21

„Andmeladude olemus ja selle funktsioonid“

Selgitav juhis

Majandus- ja Kommunikatsiooniministeerium

14.04.2023

2 / 21

Sissejuhatus ................................................................................................................................ 3

1. Andmeladude olemus ............................................................................................................. 4

1.1. Isikuandmed ja anonüümitud andmed andmelaos ........................................................... 5

1.2. Primaarandmekogu ehk operatiivbaas ja andmeladu ...................................................... 8

1.3. Millest tuleks andmeladude reguleerimisel lähtuda ...................................................... 11

1.3.1. Andmeladu on olemuslikult andmekogu osa, selle reguleerimisvajadus ............... 11

1.3.2. Andmete säilitamine andmelaos ............................................................................. 13

1.3.3. Autoriseerimine, andmete struktureerimine, logid ja muud nõuded ....................... 14

1.3.4. Andmeladu teenindab mitme asutuse andmekogu, selle reguleerimisvajadus ....... 14

2. Kokkuvõte andmelao reguleerimise vajalikkuse osas .......................................................... 17

3. Korduma kippuvad küsimused ............................................................................................. 18

3.1. Kas andmelaost võib „teenindada“ teisi andmekogusid? .............................................. 18

3.2. Kas X-teel võib andmeid vahetada vaid riigi infosüsteemi kuuluvate andmekogude

vahel? .................................................................................................................................... 18

3.3. Mis vahe on andmekogul ja infosüsteemil? Miks vormistada infosüsteemi põhimäärus?

.............................................................................................................................................. 19

3.4. Kas põhiandmeid võiks võtta ka teisest andmekogust, mitte sealt kus need algselt

tekivad? ................................................................................................................................. 20

3.5. Kas ühe andmekogu juurdepääsuhaldust saab kasutada ka teise andmekogu

juurdepääsuhalduse tagamiseks? .......................................................................................... 20

3.6. Kas ühe andmekogu sees peavad andmed liikuma X-tee vahendusel - näiteks andmete

liigutamine andmekogu erinevate kihtide või operatiivbaasi ja lao vahel? .......................... 21

3.7. Mis on andmelao ja -järve vahe lihtsustatult? ............................................................... 21

3 / 21

Sissejuhatus

Aeg-ajalt on tõusetunud vaidlused, et millised andmed andmelaos olla võivad, kas andmelaost

võib „teenindada“ teisi andmekogusid jne. Seda just isikuandmeid sisaldavate andmetöötluste

kontekstis. Seega peaks käesolev juhis tagama selle, et edaspidi on andmekogusid puudutavad

arendused ja õigusloome selgem ning sellega seotud ebakõlasid vähem. Eesmärk on

ühtlustada andmeladudega seonduv tehniline ja õiguslik raamistik.

Juhis on kõige kiirem viis ühtsete arusaamade kujundamiseks. Käesolev juhis keskendub

andmelao olemusele ning püüab selgitada selle kasutusjuhtusid. Juhist saab edaspidi

täiendada, see on ajas muutuv.

Käesolev juhis kinnitab kokkuvõttes neli peamist järeldust, millest juhises ka pikemalt juttu

tuleb:

1. Andmelaos võivad olla nii isikustatud kui isikustamata andmed.

2. Andmelaost võib andmeid õigusliku aluse olemasolul väljastada kolmandale

osapoolele (isikustatult kui isikustamata andmetena).

3. Andmekogu osaks olevasse andmelattu võib andmete laadimiseks kasutada turvalisi

kanaleid ja mitte ainult X-teed.

4. Andmelao mõistet ei tule seaduses defineerida, sellel puudub eraldi väärtus.

5. Andmelao reguleerimine andmekogu põhimääruses ei ole otseselt vajalik, kui

andmeladu toetab andmekogu pidamist andmekogule kehtivate reeglite kohaselt,

küll võib sellele viitamine tagada teatud juhtudel andmekogu kontekstis parema

õigusselguse ning anda realistliku pildi andmekogus toimuvast. Eraldi reguleerimine

on vajalik siis, kui soovitakse teha teatud erandeid.

Tausta selgitamiseks on oluline mainida, et Andmekaitse Inspektsioon (AKI) viis 2021. aastal

läbi andmeladusid puudutava küsitluse (andmeladude seire).1 Seire vastused ei andnud kindlust,

et teabevaldajatel oleks selge arusaam, kuidas andmeladusid pidada ja milliseid hoolsusnõudeid

järgida.2 Tingituna eelnevast lepitigi 2022. aasta esimeses kvartalis valitsuse tasandil kokku

analüüsida täiendavalt andmeladusid puudutavaid järeldusi ja töötada välja andmelao

loomise ja selles isikuandmete töötlemise reeglid, vajaduse korral näha ette asjakohased

seadusemuudatused.

Käesolev juhis on koostatud järgmiste asutuste koostöös: Andmekaitse Inspektsioon,

Justiitsministeerium, Siseministeerium, Sotsiaalministeerium, Haridus- ja Teadusministeerium,

Riigikantselei, Statistikaamet, Politsei- ja Piirivalveamet, Päästeamet, Rahvusarhiiv, Riigi

Infosüsteemi Amet, Tervise ja Heaolu Infosüsteemide Keskus, Siseministeeriumi

infotehnoloogia- ja arenduskeskus, Keskkonnaministeeriumi Infotehnoloogiakeskus, Maa-

amet, Rahapesu Andmebüroo, Keskkonnaagentuur.

Täname kõiki juhise koostamisse panustanud asutusi.

1 Vt lisamaterjali: AKI dokumendiregister, 28.06.2021 nr 2.3.-3/21/2278,

https://adr.rik.ee/aki/dokument/10349149 2 Andmekaitse Inspektsioon. Andmeladude seire kokkuvõte,

https://www.aki.ee/sites/default/files/seired/andmeladude_seire_kokkuvote.pdf

4 / 21

1. Andmeladude olemus

Õigusruumis ei ole üheselt reguleeritud (ei avaliku teabe seaduses ehk AvTS-is,3 ega teistes

Euroopa Liidu õigusaktides) andmelao/-aida või andmejärve mõisteid, ometi neid praktikas

kasutatakse. Andmeladusid kasutatakse sageli igapäevaste ja operatiivsete äriotsuste ja

protsesside tegemiseks ja seda struktureeritud andmetega. Andmejärvi kasutatakse suurte

andmemahtudega ja korrastamata andmetena (nn andmete soo). Seega leiab käesolevas juhises

andmekogude kontekstis kajastamist just andmeladude teema, sest andmekogudesse kogutakse

ja neis töödeldakse just struktureeritud ehk korrastatud andmeid.4 Juhises selgitatakse andmelao

(siin all ka andmeaida) olemust läbi praktiliste näidete ja tuuakse seisukoht, kas see vajaks

eraldi reguleerimist ja kui jah, siis millistel juhtudel.

Eesti õigusruumis on andmeladu või -aita reguleeritud üksikutel juhtudel. Õigusruumist võib

tuua näiteid andmeladude kohta ja neis töödeldakse andmeid viisil, kus isik otseselt tuvastatav

ei ole (näiteks tervise infosüsteemi põhimäärus (vt § 14) 5 või ka sotsiaalteenuste ja -toetuste

andmeregister (vt § 3 lg 3)) 6. See ei tähenda, et andmelaos võikski töödelda andmeid vaid

sellisel kujul. Lisaks ei ole paljude andmekogude juures andmeladu eraldi kirjeldatud, kuigi

praktika näitab, et andmelao funktsionaalsust kasutatakse ja töödeldavateks andmeteks on nii

isikustatud kui isikustamata andmed (nii tuleb välja ka inspektsiooni seire küsimustikule antud

vastustest). Siit ongi tõusetunud küsimus, et kas andmelao kasutus on midagi lubamatut, kui a)

seda ei ole eraldi reguleeritud või kui b) selles töödeldakse näiteks isikuandmeid.

Üldiselt võib kohe öelda, et andmeladu on selline infosüsteemi komponent (eraldi osa,

andmebaas), mis on optimeeritud päringute ja ärianalüüsi jaoks. Isikustatud või

isikustamata andmed ei ole andmelao eristav või oluline tunnus. Täpsemalt, andmelaos nagu

igasuguses infosüsteemis, on selgelt eristatav tehnoloogia kiht (funktsionaalsus, mida tehakse)

ja andmete kiht (millega tehakse). Andmete vaatest on oluline mõista, et anonüümne vs

isikustatud andmete töötlus sõltub asutuse vajadustest ja õiguspärasusest (st kas asutusel

on lubatud sellist andmetöötlust teha), seega on see asutuse enda otsustada ning

tehnoloogia kiht siin otsustust ei piira.

Meelespea:

✓ Kokkuvõttes on käesolevast oluline meeles pidada, et tehnoloogia kiht ehk

funktsionaalsus näitab, mida on võimalik teha ja andmete kiht näitab, milliseid

andmeid selles töödeldakse.

✓ Andmete kuju - anonüümne vs isikustatud - sõltub asutuse vajadustest ning

õiguspärasusest ja tehnoloogia kiht (lao funktsionaalsus) seda kuidagi ei piira.

3 Avaliku teabe seadus (AvTS), https://www.riigiteataja.ee/akt/106082022020 4 AvTS § 431 lg 1: „Andmekogu on riigi, kohaliku omavalitsuse või muu avalik-õigusliku isiku või avalikke

ülesandeid täitva eraõigusliku isiku infosüsteemis töödeldavate korrastatud andmete kogum, mis asutatakse ja

mida kasutatakse seaduses, selle alusel antud õigusaktis või rahvusvahelises lepingus sätestatud ülesannete

täitmiseks.“ Täpsem selgitus on toodud läbi näidete juhise alapunktis 3.7. 5 Vabariigi Valitsuse 1.12.2016 a määrus nr 138 „Tervise infosüsteemi põhimäärus“,

https://www.riigiteataja.ee/akt/103082022004#para14 6 Sotsiaalkaitseministri 27.12.2017 a määrus nr 72 „Sotsiaalteenuste ja -toetuste andmeregistri põhimäärus“,

https://www.riigiteataja.ee/akt/117082022009#para3

5 / 21

1.1. Isikuandmed ja anonüümitud andmed andmelaos

Andmeladu võib täita pelgalt statistilist/analüütilist funktsiooni, aga selles võivad sisalduda ka

isikuandmed. Andmelao tehniline ülesehitus ja selles töödeldavate andmete kuju sõltub

eesmärgist, mida see komponent andmekogu juures tagama peaks. Seega on nii isikustatud

kui ka isikustamata andmete töötlus andmelaos sisuliselt lubatud.

Näitena võib tuua, et kui andmekogus on isikuandmed ja andmekogule seadusega kehtestatud

eesmärgid on seotud isikuandmete töötlemisega, täidab andmeladu andmekogu põhifunktsiooni

ja on enamasti isikustatud, et andmeid omavahel ühitada. Nii näiteks võib „andmelao“

nimetuse all pidada keskkonda, mis andmekogule esitatud alusdokumendid kindlast formaadist

„lahti pakib“ ja eraldi andmeteks teeb (dokumente ei saaks sellisel viisil ühitada, andmeid saab).

Sellise näite puhul on see keskkond selleks, et andmekogu eesmärke üldse täita saaks, tehes

seda tänapäevasel moel. Nii tuleb andmete ühildamiseks viia need samale kujule. Mõlemad nn

filtrid – nii alusdokumendid kui neist „lahti võetud andmed“ - on selle sama andmekogu

olemuslikud osad - mõlemad tehnilised „kihid“ kuuluvad andmekogu juurde ja on vajalikud

õigusaktides seatud eesmärkide täitmiseks. Nii näiteks ei tule lugeda andmekogu kasutamisel

mitte tervikdokumente, vaid saab vaadelda andmeid reastatult, grupeeritult vm viisil. Enamasti

sisaldavad digitaalsed andmekogud neis hõlmatud süsteemides erinevaid otsinguid, andmete

koondvaadet jms.

Kindlasti on oluline mainida, et sama andmelao pinnalt võib olla võimalik luua erinevaid

tasandeid või nn kihte, kus ühele isikule on see pseudonüümitud, teisele anonüümitud andmete

vaade. Viimane tähendab seda, et ka kaudse tuvastuse risk on välistatud. Loomulikult tuleks

lähtuvalt isikuandmete kaitse üldmääruse (IKÜM) põhimõtetest7 rakendada ka igapäevase

töölaua funktsionaalsuses tehnilisi meetmeid, et andmete analüüsimisel ei vaadeldaks

isikustatud andmeid, kui see pole konkreetse ülesande täitmiseks otseselt vajalik. Võimalik, et

seda rolli täidabki andmeladu või üks osa selle funktsionaalsusest, kus dokumendid on nö

„teisendatud“ andmeteks ja neid andmeid saab mugaval viisil töödelda, pseudonüümida ja

hägustada. Näiteks kui andmeladu peetakse haldusülesande täitmiseks, siis eeldatakse andmete

õigsust ja sedagi, et haldusorgan teab, kelle osas menetlust läbi viiakse – näiteks sai haldusorgan

isiku kohta teavituse ja just tema osas tuleks rakendada ka jätkutegevusi (toimub haldusorgani

sisuline töö). Tegevused, kus isiku nimi ei ole relevantne (näiteks piirkondlik ohuhinnang),

piisaks ka hägustatud andmetest, kus isikute nimed või muud isikut tuvastada võimaldavad

andmed ei ole kogu töötluse juures vajalikud ega olulised (mittevajalik nö peidetakse ja

töötlemiseks on avatud vaid vajalik andmestik). Andmeladusid võib olla ka mitu – üks näiteks

isikustatud, teine anonüümitud statistilise vaate jaoks. Ka see ei ole välistatud. Andmeladude

funktsionaalsus ja paljusus sõltub andmekogu andmete töötlemise eesmärkidest ja vajadusest.

Pseudonüümitud andmetel põhinev andmeladu on selline andmete kogumik, kus otseselt

isikustatud (nt isikute nimedega, elukoha aadressidega vms) andmetöötlus vajalik ei ole.

7 IKÜMartiklid 5(1) ja 25(1). Viimane sätestab selgelt, et arvestades teaduse ja tehnoloogia arengut ning nende

rakendamise kulusid ning andmete delikaatsust ja ulatust ja eesmärke, rakendab vastutav töötleja nii

töötlemisvahendite kindlaksmääramisel kui ka isikuandmete töötlemise ajal asjakohaseid tehnilisi ja

korralduslikke meetmeid, nagu pseudonümiseerimine.“, https://eur-lex.europa.eu/legal-

content/ET/TXT/?uri=celex%3A32016R0679.

6 / 21

Pseudonüümitud andmestik võib ühelt poolt olla andmete kogum, mida on võimalik

taasisikustada ehk nt nimeliselt isikustatud kujule tagasi viia - depseudonüümida. Kuid

pseudonüümitud andmed võivad olla ka juba algselt ainult mingi unikaalse ID-ga eristatavad

isiku tegevused (või tegevuste tulemil tekkivad andmed), ilma et nimeliselt üldse on võimalik

konkreetse isikuni jõuda8. Sõltuvalt andmete delikaatsusest või töötlemise eesmärgist võib

seadusandja isegi eraldi ette näha, et andmekogus tervikuna töödeldaksegi andmeid vaid

pseudonüümitult ning sätestada konkreetsed juhud, millal on depseudonüümimine lubatud.

Selline kaitsemeede eeldab muidugi seda, et andmekogu eesmärke saab selliste andmetega

saavutada (näiteks eriti tundlike andmete töötlemine ja kui eesmärgiks on seatud pigem teadus

ja innovatsioon9). Olukorras, kus tegemist on andmekoguga, mille eesmärgiks on seadusandja

sätestanud ka järelevalve tegemise, ei saa igapäevaseks tööks loodud keskkonda (mida võib ka

nimetada andmelaona) kasutada peamiselt pseudonüümitult. Sellisel juhul ühitatakse andmed

konkreetse isikuga sidumiseks, et seatud eesmärke just konkreetse isiku osas täita. Siis on

vajalik, et andmed oleksid just isikustatult. Tõsi, ka eelviidatud näites saab isikustatud

andmetega nö andmekogu ühes alamosas täita analüütika ja statistika vajadusi pseudonüümitud

andmetega või koguni anonüümituna (nii on see ka sissejuhatuses toodud andmekogude näitel),

ehk andmete vorm sõltub nii andmetöötlusele seatud eesmärkidest kui ka andmekogus

rakendatud funktsionaalsustest, sealhulgas rakendatud privaatsustehnoloogiatest (lähtudes

näiteks IKÜM-i artiklist 25 – lõimitud andmekaitse põhimõte).

Sõltumata sellest, kas andmeid hallatakse pseudonüümitult terves andmekogus või selle

alamosas, võib depseudonüümimine olla ilmselt vajalik nii andmete uuendamiseks ja

kontrollimiseks (andmete terviklus)10, kui muudelgi juhtudel. Kui statistikaks või

analüüsimiseks kasutatavate andmete puhul on andmete kontrollimine või nende kvaliteet

(täpsus) oluline, tulebki andmeid hallata pseudonüümituna. Seega on pseudonüümimine ja

depseudonüümimine kindlasti lubatud, kui andmete jada tekitab ebaloogilisi järelmeid ja/või

küsimusi ning andmeid depseudonüümib andmete kontrollimiseks vastutav või volitatud

töötleja (volitatud töötlejale on selline ülesanne delegeeritud). Samamoodi võib

depseudonüümimine olla seotud andmete kontrolliga sisemiste protsesside tarvis näiteks

turvalisuse ehk juurdepääsude kontrollimise kaalutlustel (näiteks logide kontroll selle kohta,

kes mida tegi ehk kuna midagi lisati või kustutati). Kontrollimise vajadus võib tõusetuda nii

andmesubjekti huvist lähtudes, kui ka järelevalve asutuse pöördumise tulemusel.

Anonüümsena mõistetakse andmeladu vaid siis, kui selles olevaid andmeid ei saa konkreetse

isikuga või tema tegevustega taas seostada ehk isikustatud kujule tagasi viia või näiteks tuletada

koos muude andmetega nende pealt muud konfidentsiaalset teavet (ärisaladus vms).

Anonüümitud vaade on tegelikult lõpptulemus, kus üks kiht ehk funktsionaalsus andmelaos

täidab sellist rolli, et hoida andmeid konstantselt ehk neid ei muudeta. Näitena võib tuua

olukorra, kus eesmärgiks ongi vaadelda statistilisi juhuarve ja mitte korduvust - isikuandmed

8 Sarnane olukord on näiteks veebiküpsiste puhul. Veebilehe pidaja ei tea (seda juhul, kui pole sisselogitud

kasutaja), kes nimeliselt arvuti taga on, kuid läbi küpsise omistatud unikaalse ID saab veebilehe pidaja eristada

erinevaid veebilehe külastajaid ja nende kasutusmustreid. 9 Vt näiteks inimgeeniuuringute seadus, § 24, https://www.riigiteataja.ee/akt/113032019064#para24 10 Andmete terviklus on andmete õigsus ja täielikkus. Vt küberturvalisuse seaduse § 7 lõike 5 alusel kehtestatud

ettevõtlus- ja infotehnoloogiaministri 16.12.2022. a määrus nr 101 „Eesti infoturbestandard“,

https://www.riigiteataja.ee/akt/121122022034. Varasemalt tulenes AvTS § 439 lõike 1 punkti 4 alusel

kehtestatud Vabariigi Valitsuse 01.01.2008. a määrusest nr 252 „Infosüsteemide turvameetmete süsteem“,

https://www.riigiteataja.ee/akt/115092020015.

7 / 21

tekivad üksikute kirjetena ja korduvus ei ole oluline (näiteks kogutakse isikute kohta andmeid

- meesterahvas, tema vanus, maakond ja mõni statistiline näitaja nagu haigestumine - andmeid

sama isiku kohta ei uuendata ehk taashaigestumist ei järgita ja andmeid ei kontrollita). Seega,

võivad andmelaos hoitavad andmed kindlasti olla ka anonüümitud andmed, kui konkreetse

asutuse andmekasutus ja andmelao ülesehitus on selline, et andmelattu edastataksegi

isikuandmeid ainult anonüümituna. Ka siin on võimalik kaitsemeetmena ära piiritleda, et

andmeladu ongi vaid anonüümitud statistiline andmestik ja sinna tohibki kanda vaid

anonüümitud andmeid (see oleks nö suuniseks ka volitatud töötlejale). Siinjuures on

andmekogu terviku mõttes oluline taas tuua, et see ei tähenda nagu ei oleks andmekogus endas

muid andmete kogumikke ehk andmeladu, kus algandmed „lahti pakitakse“ ja ühitatakse enne

anonüümitud andmelattu kandmist. Samas võivad need olla ka eraldi kambrid ühes andmelaos.

Nagu eelnevalt juba viidatud, siis võib andmekogu juures olla ladusid ka mitu – üks isikustatud,

teine pseudonüümitud või anonüümitud vaate jaoks, mille kasutajaskond on erinev (seda nii

asutuse siseselt kui väliselt, lähtudes õiguslikest alustest). Nii võib andmekogu terviksüsteemis

olla ka mitu paralleelselt paiknevat andmeladu ja nende eristamiseks võib neid ka erinevalt

nimetada. Samas võib olla süsteemi ülesehituses ka ühe isikustatud andmelao all omakorda

anonüümitud alamandmeladu. Seega erinevad andmeladude ülesehitus ja paiknemine

terviksüsteemis sõltuvalt konkreetse teabevaldaja vajadustest ning ühte ja õiget vastust siin olla

ei saagi. Nimetatud ülevaade esitatakse arhitektuurilises dokumentatsioonis, mis on riigi

infosüsteemi haldussüsteemi (nn RIHA-sse) esitatav materjal.11

Olukorras, kus andmelao andmeid näevad erinevad isikud teenuste raames anonüümsete

andmetena, kuid andmelao andmeid saab iga isiku kohta siiski algandmetes uuendada, on

tegemist ikkagi pseudonüümitud andmelaoga, sest andmelao pidaja saab andmeid kontrollida

ja vajadusel uuendada (näiteks eeltoodud näide meesterahva kohta, kus nüüd oleks eesmärk aga

siduda faktiline teave aasta lõikes sama meestrahvaga – näiteks nakatumiste korduvus ühe isiku

lõikes). Nii ei hinnata andmelao reguleerimisel mitte seda, kuidas kolmandad isikud

andmelao andmeid näevad, vaid seda, kuidas andmeladu ennast peetakse (näiteks kas

isikuandmed on anonüümitult ja need ei muutu ajas või uuenevad või täienevad need ajas sama

isiku kohta). Kui andmekogu haldaja (vastutav või volitatud töötleja) ise saab andmeid

uuendada, kontrollida ja taasisikustada, on õige rääkida ikkagi pseudonüümitud andmelaost ja

seejuures võib kolmandatele isikutele olla juurdepääs anonüümitud andmete vaatele

(andmekogu andmekasutuse juurdepääsude täpsustavas sättes saab sellele näiteks eraldi

viidata12).

Juhul, kui andmelao andmeid soovitakse kontrollida ehk teada, mida sinna teatud

anonüümimise tehnoloogiaid kasutades kanti ja kas need on ka õiged, ei ole andmeladu

anonüümitud kujul (see seisukoht võib tulevikus privaatsustehnoloogiate arenguga muutuda).

Anonüümimine ise võib toimuda kolmes kohas: a) algsüsteemis, b) andmete edastamisel

11 Vt Vabariigi Valitsuse 28.02.2008. a määrus nr 58 „Riigi infosüsteemi haldussüsteem“, § 18 lg 2 p 5 -

andmete üldandmeteks on ka andmekogu tehnilise kirjelduse dokumendid, kus sisalduvad andmekogu

arhitektuuri, talitlusprotsessi, koosvõime nõuetele vastavuse, haldamise reeglite kirjeldused ja muud olulised

andmekogu kohta käivad tehnilised kirjeldused ning andmekogu põhimäärus või selle kavand,

https://www.riigiteataja.ee/akt/106082019018#para18. 12 Vt nt tervise infosüsteemi põhimääruse § 14 normi, kus on toodud andmelao kasutamine, sh selle eesmärk, see

kellele see on suunatud ja kuidas andmetöötlus toimub. Tegemist ei ole küll anonüümitud andmelaoga aga

sarnaselt sellele näitele saab selguse luua ka muudel juhtudel.

8 / 21

andmelattu või c) andmelaos. Ka neist sõltub andmelaos hallatavate andmete tähenduse

sisustamine.

Meelespea:

✓ Kokkuvõttes on oluline rõhutada, et andmelaos ei ole keelatud töödelda

isikuandmeid ja andmelaos peetavate andmete olemus sõltub eesmärgist (mida on

vaja) ja kasutatavast tehnoloogiast (kas saab töödelda vähem riivavamal moel), kuid

kõik versioonid on võimalikud.

1.2. Primaarandmekogu ehk operatiivbaas ja andmeladu

Funktsionaalsuse juures ei saa mööda minna ka tõusetunud diskussioonist – kus andmed siis

asuvad – primaarandmekogus või laos? See on tekitanud diskussiooni selle üle, et kas tegemist

on lubamatu kopeerimisega? Nagu eelnevalt selgitatud, siis on andmekogu eesmärkide

täitmiseks vajalik töödelda andmeid ja seega peavad need olema sobival kujul. Edastatud

andmestiku eristamiseks ja andmekogu eesmärkide täitmiseks võivad olla samad andmed

andmekogus mitmes formaadis – nii algselt edastatud alusdokumendis kui ka teistes

andmekihtides (andmestik, alamandmekogu või andmeladu). Kui andmekogusse esitatakse

andmeid või dokumente teatud kujul (kas dokumendina või näiteks

kinnitatuna/digitembeldatuna), siis salvestatakse need digitaalses andmekogus enamasti ka

eraldi üksikute andmetena, et neid eesmärgipäraselt töödelda ja teiste andmekogudega X-teel

vahetada.13

Andmete töötlemiseks ja andmete vahetamiseks teiste riigi infosüsteemi kuuluvate

andmekogudega või teiste süsteemidega (näiteks teenuse osutajad), ei saa edastada mitte kogu

edastatud andmestikku või kogu dokumenti, vaid konkreetseid andmeid. Vastasel korral

rikutaks andmete edastamisel õigusaktides sätestatud kohustusi (AvTS-ist lähtuvalt

andmeandjad ja edastatavad andmed14 ja IKÜM-ist lähtuvalt minimaalsuse põhimõte15).

Igapäevatööd tehes soovitakse andmeid töödelda nii, et neid saab reastada ja siduda, mitte avada

ja sulgeda edastatud digikonteinerit. Seetõttu on mõistetav, miks tekitatakse andmekogus

erinevate funktsionaalsustega töödeldavaid alamandmestikke või ladusid. See on vajalik

andmekogusiseste funktsioonide täitmiseks, mis omakorda täidavad andmekogu eesmärgina

kehtestatud peamisi eesmärke.

Selliseid näiteid võib tuua ilmselt iga andmekogu pinnalt mitmeid. Sõltuvalt andmekogu

eesmärgist ja selle funktsionaalsustest, on samade andmete eraldi paigutus vältimatu, et

andmekogu eesmärke vastutava ja volitatud töötleja või siis ka andmekogu kasutajate vaatest

13 Vt nt Vabariigi Valitsuse 28.02.2008 a määrust nr 58 „Riigi infosüsteemi haldussüsteem“,

https://www.riigiteataja.ee/akt/106082019018. Selles eeldatakse metaandmete või muu andmekogude vahel

vahetatava teabe andmekirjeldusi. Vt ka Vabariigi Valitsuse 23.09.2016 a määrus nr 105 „Infosüsteemide

andmevahetuskiht“, https://www.riigiteataja.ee/akt/106082019017. Ka see räägib andmetest, mida X-teel

vahetatakse. 14 Vt nt AvTS § 435 lg 1: „Andmekogu põhimääruses sätestatakse andmekogu pidamise kord, sealhulgas

andmekogu vastutav töötleja (haldaja) ja vajaduse korral volitatud töötleja, andmekogusse kogutavate andmete

koosseis, andmeandjad ja vajaduse korral muud andmekogu pidamisega seotud korralduslikud küsimused.“ 15 IKÜM, art 5 lg 1 alapunkt c, https://eur-lex.europa.eu/legal-content/ET/TXT/?uri=celex%3A32016R0679.

9 / 21

täita. Seega tekivad tahes tahtmata andmed erineval kujul, kuid see ei tähenda, et tegemist oleks

lubamatu koopiaga.

Eeltoodud näidetes on andmeladu üks andmekogu funktsionaalsusest. Seega ei saa andmed

asuda „lihtsalt kusagil“ ehk väljaspool andmekogu raamivat süsteemi. Oluline on, et

andmekogu ja seda ümbritsev süsteem oleks terviklik ja kooskõlas õigusaktides sätestatud

raamidega - milliseid andmeid kogutakse ja säilitatakse, kes haldab, kes saab juurde,

kellele andmeid väljastatakse ning kuivõrd on tagatud piisavad turvameetmed jms. Nii

tuleb ka kõikide andmetöötluste korral – ei ole oluline mitmel tasandil – tagada ka logid jm

nõuded (vt rohkem alapunkt 1.3.3).

Võimalikku näidet saab selgitada kõrval

oleva joonisena, kus andmekogu osaks

on nn operatiivbaas ehk dokumendid,

mis sisse tulid, kui ka andmeladu, kus

asuvad andmed. Viimased põhinevad

sisse tulnud dokumentidel, neid saab

mugaval viisil töödelda - reastada,

siduda ja edastada teistele näiteks

teenuste pakkumiseks.

Mõlemad eelviidatud andmekihid

(algdokumendid ja „lahti pakitud“

andmed) moodustavad andmekogu

olemusliku terviku. Selguse huvides

tuleks andmekogu põhimääruses tuua,

et andmekogu on mitmetasandiline/-kihiline ning ühe andmestiku sellest moodustavad alg- või

a) Näiteks selleks, et teha tervishoiuteenuse osutaja edastatud vabad ravijärjekorra

ajad patsiendile digiregistratuuris kättesaadavaks ja siduda vaba vastuvõtuaeg

patsiendile väljastatud saatekirjaga, on vaja andmed omavahel seostada. Samad

andmed teenuse osutaja kohta on esitatud nii vabades ravijärjekorra aegades kui

ka saatekirja dokumendis. Isikuandmed on samuti nii algdokumendis (saatekiri)

kui ka digiregistratuuris, et aeg kinnitada ja saatekiri sellega siduda.

b) Isikuandmete töötlemine toimub ka muude funktsionaalsuste täitmisel. Lisaks

algandmetele, mis teenuse osutaja poolt ravidokumendis edastati, toimub isiku

nime ja isikukoodi töötlus ka kontaktandmetes, mida isik saab näiteks läbi

iseteeninduse esitada. Isikuandmete töötlus on vajalik ka iseteenindusse

sisenemiseks ja samad andmed - isiku nimi ja isikukood - jäädvustatakse ka

näiteks logides.

Seega oleks võimatu täita sellist nõuet, et isiku nimi ja isikukood võiks kogu

andmekogus esineda vaid üks kord. Oluline, et tegevused on andmekogu eesmärke.

silmas pidades lubatud ja eesmärgipärased ning et tegevus logitakse.

10 / 21

alusdokumendid.16 Kui seda eraldi määratud ei ole, on see põhjendatav töötlemise eesmärkide

tagamisega, sõltuvalt kehtestatud nõuetest (kas andmeid esitatakse avalduste, taotluste,

deklaratsioonidena ja/või otsetäidetava vormi kaudu jne). Tuues paralleeli võib vaadelda seda

kui sarnast olukorda pabermaterjalidega, kus üks ja sama paber võib olla kahes kohas

(kopeerituna erinevateks eesmärkideks) või on paber kantud arhiivi ja selle andmed sisestatuna

infosüsteemi, lähtudes töötlemise eesmärkidest ja säilitamise tähtaegadest. Samas on oluline

rõhutada, et taas läbipaistvuse huvides tuleks andmekogude puhul selle põhimääruses eristada,

mida sinna kantakse. See tähendab, et siin on sisuline vahe, kas sinna kantakse terve dokument

(mida see sisaldab) või ainult üksikud andmeväljad, mis on olulised (nt kas kohtumäärus

teovõime piiramise kohta või ainult andmeväljana resolutsioon teovõime piiramise ulatuse

kohta). Niisamuti tuleb kaaluda ja eristada erinevate andmestike säilitamise tähtaegasid (nt

alusandmete kui dokumentide säilitamise erisus kui andmed on süsteemi andmetena

salvestunud vms).

Andmekogu funktsionaalsused on ellu kutsutud täitma andmekogule seatud eesmärke ehk

funktsionaalsus aitab täita seda, milleks andmeid üldse koguma hakati. Selleks võib olla vajalik

andmekogu siseselt salvestada andmeid ühes või teises andmekihis (varasemalt toodud näide,

kus on olemas algandmetena saatekiri ning andmete sidumiseks digiregistratuuris esitatakse

isikuandmed, mis esinevad juba digisaatekirjal). Oluline on, et nii ühel kui teisel viisil

salvestatud andmete säilitamisel tuleb järgida säilitamisele kehtestatud tähtaegu (vt täpsemalt p

1.3.2.). Samuti võib tekitada küsitavusi see, kui andmed hakkavad erinema – ehk parandatakse

näiteks ära „lahti pakitud andmed“, kui neis avastatakse viga, kuid algne kinnitatud dokument

jääb andmete edastaja poolt muutmata (vt täpsemalt p 1.3.3).

Meelespea:

✓ Kokkuvõtvalt võib tuua, et andmekogus võib olla eraldi algandmestik ja eraldi

andmeladu nende andmete kiireks töötlemiseks andmeridade pealt (arvutused,

otsingud jms).

✓ Tehniline ja kihiline eristus, kus üks osa on nimetatud andmelaona, aga sisaldab

samu andmeid, ei tähenda, et tegemist on lubamatu koopiaga. Erinevad tehnilised

funktsionaalsused ja andmekihid on loodud kooskõlas andmekogu eesmärkidega

ja aitavad täita andmekogu eesmärke selleks õigustatud isikute poolt.

✓ Oluline on, et andmete kogu töötlemise õiguspärasuse (sh töötlemise eesmärk ja

viis, andmekoosseis, juurdepääs, andmete õigsus, säilitamine, töötlemise

jälgitavus) tagamiseks tuleb järgida kehtestatud nõudeid kogu andmekogu

andmete osas tervikuna.

16 Näiteks tervise- ja tööministri 06.03.2019 a määrus nr 16 „Tuberkuloosiregistri põhimäärus, § 3 lõiked 1 ja 2,

https://www.riigiteataja.ee/akt/112032019021, või 20.05.2016 a määrus nr 40 „Töövõime hindamise ja

töövõimetoetuse andmekogu asutamise ja pidamise põhimäärus, § 3,

https://www.riigiteataja.ee/akt/119022020002.

11 / 21

1.3. Millest tuleks andmeladude reguleerimisel lähtuda

Käesolevas alajaotuses tuuakse peamised alateemad lähtuvalt praktikas üles kerkkinud

küsimustest. Näiteks kas andmeladu peab olema ühe andmekogu osa või kui kaua võivad

andmelaos olla andmed säilitatud jms. Andmelao juures tuleb järgida samu nõudeid –

turvanõuded, juurdepääsuõigused, õiguslik alus jms – nagu kogu andmekogu pidamiselgi.

Rakendada tuleks kõiki asjakohaseid meetmeid, mis tagavad andmetöötluse kooskõla

õigusaktides kehtestatuga. Ei andmelao ühes ega teises nn kihis - olgu siis operatiivbaas või

andmeladu - ei saa olla andmeid, mida pole lubatud koguda seaduse või põhimääruse kohaselt.

Oluline on rõhutada, et andmete töötlemine oleks kooskõlas õigusaktidega, seda nii

andmete kogumise, nende turvalisuse kui ka muude nõuete tagamisel.

1.3.1. Andmeladu on olemuslikult andmekogu osa, selle reguleerimisvajadus

Nagu juhise sissejuhatuses viidatud, on andmeladude kajastamine andmekogude põhimäärustes

erinev – osalt on see sätestatud, osalt mitte ning ka regulatsiooni sisu on väga erinev (mõnel

juhul on see detailsem, mõnel juhul aga mainitud vaid registri ülesehituse juures). Vastus

küsimusele, kas andmeladu tuleks siis alati põhimääruses eraldi reguleerida või mitte, ei ole

ühene ja sõltub teatud erisustest. Teatud juhtudel oleks andmelao eraldi reguleerimine

põhimääruses mõistlik, osadel juhtudel vajalik. Siinkohal saame tuua taas näiteid.

Andmelaos kui andmekogu olemuslikus osas ei saa töödeldavate andmete kategooriad väljuda

andmekogu kohta käivast seadusest või põhimäärusest. Teisisõnu, ei saa andmekogu juurde

kuuluvas andmelaos (olgu siis tehnilises mõttes eraldi alamandmekogu või põhibaasi

funktsionaalsusega töödeldav andmestik) olla andmeid, mis väljuksid selle konkreetse

andmekogu andmetest, mida sinna koguda tohib.

Andmekogu asutatakse konkreetse ülesande täitmiseks ja andmekogu eesmärk ning sellesse

kogutavad andmed peavad olema kaetud andmekogu aluseks oleva seaduse või põhimäärusega

ehk olema piiritletud (seaduslikkus).17 Kogu avaliku võimu tegevus peab olema

põhiseaduspärane ja rajanema seadustel. Mõistagi ei saa iga otsust ja toimingut seadustes

üksikasjalikult kirjeldada, seaduse alusel võib anda täpsustavaid määrusi jt õigusakte, mis

omakorda peavad olema kooskõlas kõrgemat õigusjõudu omava aktiga.18 Seega ei saa

andmelaos, mis on andmekogu osa, olla midagi rohkemat kui see, mida seadus võimaldab. Eriti

oluline on see isikuandmete kogumise puhul, kuid mitte ainult. Ka teiste andmete (ärisaladus,

ettevõtja kohustus esitada riigile andmeid), kogumine peab olema ettenähtav ja seega

piiritletud. Kui töödeldavad andmed ja töötlemise eesmärk ei välju eelviidatud piiridest, jääb

17 Põhiseadus, § 3. Isikuandmete osas vt ka isikuandmete kaitse seaduse rakendamise seaduse (778 SE)

seletuskirja alapunkti 3.2 „Seaduste muutmise põhimõtted“. Selles tuuakse kolm põhilist sammast, mida

seadusloomes järgida – seaduses tuleb tuua andmekategooriad, nende säilitamise tähtaeg ning hinnata

andmekogus toodud tegevusi seaduses toodud volitusnormi piisavusega,

https://www.riigikogu.ee/tegevus/eelnoud/eelnou/9d1420bb-b516-4ab1-b337-17b2c83eedb1. Vt ka

Andmekaitse Inspektsiooni juhist „Andmekogude juhend“, p 2.4 „Kuidas seadusega põhiõiguste riivet

pehmendada?“, https://www.aki.ee/sites/default/files/dokumendid/andmekogude_juhend.pdf. 18 Põhiseaduse kommentaarid, § 3, https://pohiseadus.ee/sisu/3472.

12 / 21

ikkagi üles küsimus, et kas sellisel juhul tuleb andmeladu eraldi välja tuua ja reguleerida või

mitte? Küsimusele vastamiseks tasuks selgitada erinevaid võimalusi.

Näiteks võib infosüsteem või registri regulatsioon olla hõlmatud ühe või mitme andmekoguga

– sealjuures võib olla andmeladu üks selle eraldi osi (näiteks tervise infosüsteem ja

sotsiaalteenuste ja -toetuste andmeregister).19 Oluline on see, kas kogutavad andmed jäävad

andmekogu õiguslikesse raamidesse ja kas eesmärk on andmekogu asutamisel kaetud. Milliseid

funktsioone konkreetselt andmeladu täidab, on erinev. Kindlasti ei tule eraldi reguleerida

olukorda, kui andmeladu täidab igapäevaseid andmekogu eesmärkides seatud ülesandeid

ehk andmete vormile, säilitamisele, juurdepääsudele, turvanõuetele vm nõuete osas

erisusi ette ei nähta. Sellisel juhul ei oma see eraldi tähendust, sest ladu ongi mõeldud näiteks

dokumentidest andmete „lahti pakkimiseks“ ja kogu mugava töötlemise tagamiseks (üldpildi

infosüsteemist saab arhitektuurijooniselt). Samas võib selle äramainimine aidata kaasa

läbipaistvuse tagamisele, ehk tervikpilt peaks olema kooskõlas reaalsetete tegevustega. Näiteks

on tervise infosüsteemis toodud alamandmestikud ja seetõttu ka eraldi andmeladu, moodustades

ühe eraldiseisva andmestike hulga ja mille vorm erineb muudest andmekogu andmetest

(viidatakse kohustusele viia läbi igapäevaanalüüse isikuid otseselt mittetuvastaval viisil). Eraldi

reguleerimine on vajalik selleks, et just sellele eraldi osale anda näiteks kolmandatele

osapooltele juurdepääse (nende jaoks anonüümitud andmestik). Eraldi alamosade eristamine

võib olla vajalik ka isikustatud andmetele juurdepääsude eristamiseks(aitab määratleda

erinevate isikute juurdepääsulatust).20 Andmelao eraldi reguleerimine võib olla põhjendatud ka

siis, kui seal on statistiline andmestik ja näiteks sellel võiks olla seetõttu madalam turvaaste

(saab viidata konkreetsele andmekogu osale, millele kehtib teine reeglistik). Samuti, kui

soovitakse eristada anonüümitud andmelao andmete säilitamist või teha mõni muu erisus.

Andmeid võib avaldada andmelaost ka otse veebilehel anonüümse andmestikuna või näiteks

jagada erinevate õigustega juurdepääse. Kui andmelao pinnalt teenindatakse näiteks teisi

asutusi otsejuurdepääsudega (erinevate õiguste ja vaadetega aknad), sõltub reguleerimise

vajalikkus sellest, millistele andmetele on juurdepääs lubatud.21 Juurdepääs võib olla

isikustatud või isikustamata andmetele ja loomulikult on võimalik rakendada eraldi

autentimisvahendeid.

Kindlasti tuleb toetada lähenemisviisi, kus andmekogu põhimäärus täpsustab erinevaid

töötlemisviise ja andmetele juurdepääsude andmist või andmete avaldamist, suurendades

seeläbi usaldust andmetöötluse vastu.

19 Lisaselgitus: alamregistrite arv ei ole piiratud, nii näiteks on lennuohutuse järelevalve infosüsteemi pidamise

põhimääruse kohaselt ühte infosüsteemi koondatud 11 alamregistrit,

https://www.riigiteataja.ee/akt/117062021008. 20 Näiteks – küll mitte andmelaona aga hea näitena – on eraldi reguleeritud juurdepääsud maksukohuslase

registri alamregistrile, töötamise registrile (https://www.riigiteataja.ee/akt/109082022007#para25b1). Eraldi

hoitavad andmekogumikud võimaldavad määrata eesmärgipäraselt juurdepääse, kus kogu andmestik ei ole

kõigile vajalik, seega on võimalik teatud alustel grupeeritud ja hoitud andmetele anda juurdepääs vaid vajalikus

ulatuses. 21 Vt nt tervise infosüsteemi põhimäärus, § 14 lõiked 1–3, mis selgitavad andmelao juurdepääse ja andmete

avaldamist avaandmetena, https://www.riigiteataja.ee/akt/103082022004#para14.

13 / 21

Järgnevalt ilmestame kasutusviiside erinevaid juhte.

1.3.2. Andmete säilitamine andmelaos

Kui andmeladu on andmekogu osa, siis nagu andmete koosseis ei saa olla laiem kui

andmekogu aluseks oleva seadusega või põhimäärusega lubatu, ei saa ka andmelaos

kasutada andmeid pikemalt, kui õigusaktides kehtestatud andmete säilitamise tähtaeg

ette näeb (AvTS kohustab reguleerima selles hoitavaid andmeid ja seega peab teadma, kui kaua

midagi alles hoitakse, tagades taaskord teabe töötlemise seaduslikkuse). Ka siis, kui andmed

anonüümitakse ja kantakse statistilisse anonüümsesse alamandmebaasi (nn lattu), puudub

isikustamata andmete hoidmisel küll otseselt puude eraelu riivega, kuid kuna ka anonüümitud

andmed moodustavad andmekogus säilitatavate andmete osa, tuleks luua siingi selgus, et kui

kaua riiklikus andmekogus andmed siis hoitakse. Seda teavet võivad soovida teada ettevõtted,

mille kohta andmeid hoitakse ja mis ei ole isikuandmed, aga ka teised isikud, kes neid andmeid

kasutavad, olgu siis haldusülesanneteks või teadustööks.

Lähtekoht, et andmed on

anonüümitud ja justkui

seetõttu eraldi reguleerimist

ei vaja, ei ole päris õige. Kui

teave tekib (andmed) ja see

kantakse ja säilitatakse

andmekogus, tuleks seegi

selgelt reguleerida. Toome

kõrval sellekohase näite.

a) Andmeladu kui igapäevane töövahend andmekogu pidajale. Andmeladu võib olla

igapäevategevuste tarbeks loodud töövahend, et töödelda just isikustatud andmeid ja

võimaldades sama andmekogu andmeid erinevatest „nurkadest“ ühitada ja muuta. Selle

funktsioonid võivad olla lähtuvalt asutuste vajadustest erinevad.

b) Andmeladu kui andmestik statistikaks. Andmeid kasutatakse asutuse enda poolt

andmekogu statistiliste eesmärkide täitmiseks (nt poliitika kujundamiseks, igapäevased

raportid jms).

c) Vastavalt õigustele antakse teistele ka teabe saamiseks juurdepääse. Teistele

isikutele/asutustele andmetele juurdepääsu andmine vastavalt andmelaos kavandatud

teenustele. Mida ja kellele näidata – kas isikustatult või anonüümitult - sõltub õigustest.

d) Andmekogu andmelao pealt andmete otse avalikustamine (avaandmed). Üldine

statistiline teave, mida võib avaldada ehk isiku tuvastamine või muu konfidentsiaalse teabe

lubamatu avaldamine on välistatud. Graafiliste avaandmete esitamine toimub turvaliselt

(tulemüür, esitlusserverile puudub juurdepääs jne).

Näiteks kui andmelao andmed on anonüümselt olemas, siis võib

ka siin näha ette erisuse andmelao anonüümitud andmetele ehk

tuuagi välja, et peetakse ka anonüümitud andmeladu mille

andmed on „x“ tähtajani. Näiteks on andmekogul ühed

eesmärgid – loa taotlused, menetlused. Kui load on väljastatud

ja kõik menetlused lõppenud ja neid hoitakse näiteks seoses

vaidlustamisvõimalustega vaid viis aastat, siis võib teatud

faktiliste andmete säilitamine olla põhjendatud ka statistikaks

pikemalt, et kujundada valdkondlikku poliitikat. Nii täidavad

menetlusega seotud andmed lühiajalist eesmärki ja

statistika/poliitika kujundamine pikemat eesmärki ja siit ka

pikem säilitamise tähtaeg. Nii tulekski see erisus selgelt

reguleerida.

14 / 21

1.3.3. Autoriseerimine, andmete struktureerimine, logid ja muud nõuded

Andmeladude haldamisel, mis on andmekogu osa, tuleb järgida kõiki samu põhimõtteid nagu

andmekogudegi puhul, see on selle olemuslik osa. Seega andmete struktureeritus, turvanõuded

jms, sealhulgas juurdepääsude haldus ja autoriseerimine, kui andmelaole võimaldatakse

otsejuurdepääse.

Isikustatud andmestike puhul tuleb kindlasti tagada logide haldus, see on sarnane muu

andmetöötlusega terves andmekogus, ehk üldised põhimõtted siin ei muutu. Seega tuleb läbi

mõelda ka logide süsteem, mis võimaldab tuvastada muudatused või andmete vaatamise kas

siis ühes või teises andmekihis. Ehk kui andmekogu kasutajad pärivad dokumente või

pakutavate teenuste raames töödeldakse „lahti pakitud“ andmeid, tuleks isikuandmete

töötlemine logida nii ühel kui teisel juhul. Loomulikult ei pruugi see nõue kehtida anonüümitud

andmete töötlemisel andmelaos, sest nende vaatamine on sarnane avaandmete käsitlusega.

Samas ei tähenda see aga seda, et andmelao osas ei kehtiks muid kohustusi (juurdepääsude

haldus või andmete turvaline avaldamine jms).

Erisusena võib reguleerida ka anonüümitud andmete turvaklassi, kui selles hoitakse vaid

anonüümitud andmeid. Ka see on võimalik andmekogu põhimääruses ära määratleda.

Kindlasti tuleks pöörata tähelepanu ka andmete muutmisele. Olukorras, kus andmed

muudetakse andmelaos, aga andmed jäävad algdokumendis muutmata, erineksid

funktsionaalsustes kasutatavad andmed (lahti pakitult) algandmetest, mis andmekogu pidajale

esitati. Andmete kvaliteet peaks olema aga ühesugune, sõltumata andmete paiknevusest. See

tähendab omakorda protsesside kaardistust andmehalduse kontekstis ja õigusselguse

tagamiseks on vajalik õigused ja kohustused sätestada täpsemalt andmekogu põhimääruses,

nagu seda on enamasti ka tehtud (andmete muutmise/uuendamise protsess).

Meelespea:

✓ Kokkuvõttes võib tuua, et andmekogu juurde kuuluva andmelao andmete koosseis

ja andmete säilitamise tähtaeg ei saa erineda andmekogule kehtestatud nõuetest

(mis andmeid võib koguda ja kaua neid säilitatakse).

✓ Andmeladu kui ühte tehnilist võimalust andmestike halduses ei pea andmekogu

põhimääruses eraldi reguleerima, kui see täidab andmekogu peamisi eesmärke (nt

kui alusdokumendid „võetakse“ andmeteks lahti). Kindlasti tuleks andmelao

puhul eraldi reguleerida see, kui soovitakse kehtestada teatud erisusi - andmete

vorm, juurdepääsude haldus, turvanõuded jms.

1.3.4. Andmeladu teenindab mitme asutuse andmekogu, selle reguleerimisvajadus

Andmelao reguleerimise vajalikkuse osas, kus selle eesmärk on tagada andmetöötlus erinevate

andmekogude osas, tuleks taaskord avada mõtet läbi näidete.

Andmeladu võib olla kui üks laohoone, kus on eraldi üüritavad ruumid. See tähendab, et

laoruumide omanike kaup ehk andmed hoitakse teiste omadest eraldi, igal vastutaval töötlejal

on oma ruum ja oma ruumi võti. Nii on võimalik, et mitu erinevat asutust (vastutavat töötlejat)

15 / 21

kasutavad ühte ja sama volitatud töötlejat ehk tema teenuseid (nö üürivad laos ruumi pinda).

Volitatud töötleja võib omada ühte andmeladu (platvorm), milles üüritakse erinevatele

vastutavatele töötlejatele laoruume. Seega on õigused ja kohustused hoitud lahus, andmeid

ei ristkasutata ja erinevatele „ruumi üürijatele“ üksteise andmeid ei näidata. Volitatud

töötleja peab täitma kõiki kohustusi vastavalt õigusruumis toodule ja lähtuvalt iga vastutava

töötleja juhistest, mis võivad olla erinevate andmekogude kontekstis erinevad. Nii on iga

andmekogu juures näiteks ära toodud, et andmekogul on analüütiline andmeladu, seda haldab

volitatud töötleja X. Tehniliselt ja õiguslikult omab iga andmekogu „oma ruumi“, kus toimub

nende andmetöötlus. Volitatud töötleja X peab tagama, et erinevate andmekogude andmeid (see

tähendab ka analüütilisi) ei näe otse ükski teine andmekogu vastutav töötleja (andmeid saaks

näha sarnaselt teistele isikutele mõeldud teenuste kaudu).

Olukord, kus erinevate asutuste ehk vastutavate töötlejate andmed ühte andmelattu aga kokku

kantakse, eeldab sellekohaseid õiguslikke aluseid. Ehk sellisel juhul tuleb eraldi analüüsida, kes

nimetatud andmeladu peab, millisel eesmärgil ning millisel kujul on selles peetavad andmed.

Anonüümsete andmete korral (kõik mis kanti nii ka jääb) võib tegemist olla nt avaandmetega,

mis koondatakse ühe isiku poolt kokku, kuid kes iseseisvalt alusandmeid ei näe. Sisuliselt

toimuks justkui andmekogudest andmete väljastamine ehk statistiliste näitajate jagamine –

tegemist ei oleks juurdepääsupiiranguga teabega – näiteks väljastatud tegevuslubade arv,

sõidukite arv vms. Sellist eesmärki täidab täna avaandmete teabevärav.22

Isikustatud andmete töötlemise korral tuleb õiguslike aluste olemasolu eraldi hinnata. Kui

erinevate andmekogude andmeid soovitakse isikustatult ühte kokku kuhjata ja neid omakorda

mingitel eesmärkidel töödelda, ei saa enam rääkida andmetöötlustest ühe andmekogu

eesmärkidel ja andmete piires. See eeldab eraldiseisvat alust. Andmekogu asutatakse AvTS-i

kohaselt konkreetse ülesande täitmiseks23 ning luues uue andmete kogumise ja töötlemise

eesmärgi, räägime me uuest riigi infosüsteemi kuuluvast andmekogust (mitte laost, mis võib

olla uue andmekogu funktsionaalsus). Seega ei saa luua „lihtsalt ladu töötluseks“ vaid eraldi

asutades luuakse siiski uuel eesmärgil andmekogu kui selline.

Olemasolevatest andmekogudest nende kõikide andmete koondamisel lihtsalt uude

andmekogusse töötlemise hõlbustamiseks, tekitaks küsimuse aga nii seatud uuest eesmärgist

ehk ülesandest, aga ka algandmekogude vajalikkusest.24 Kui eesmärk on võimaldada erinevate

andmekogude vahel andmete pärimist – olgu siis konkreetse teenuse tagamiseks või ka

statistikaks (kui andmekogu eesmärgina on see seatud), tuleks see reguleerida läbi erinevate

andmekogude ja andmeandjate regulatsiooni. Iga andmeandja ja soovitud andmepäringu puhul

tuleb selgitada nende andmete pärimise vajalikkust ja kooskõla selle andmekogu eesmärgiga,

kuhu neid andmeid siis kandma hakatakse (ehk kuhu need edastatakse).25 Ei ole välistatud, et

kui olemuslikult on vaja näiteks kahe andmekogu andmete pidev ühildamine ja kus tegelikult

22 Vt siit: https://avaandmed.eesti.ee/. AvTS § 29 lõike 6 kohaselt peavad masinloetaval kujul olevad avaandmed

juurdepääsetavad Eesti teabevärava kaudu. 23 AvTS § 431 lg 1: Andmekogu on riigi, kohaliku omavalitsuse või muu avalik-õigusliku isiku või avalikke

ülesandeid täitva eraõigusliku isiku infosüsteemis töödeldavate korrastatud andmete kogum, mis asutatakse ja

mida kasutatakse seaduses, selle alusel antud õigusaktis või rahvusvahelises lepingus sätestatud ülesannete

täitmiseks. 24 Vt ka vt ka AvTS § 433 lg 2: keelatud on asutada ühtede ja samade andmete kogumiseks eraldi andmekogusid. 25 AvTS § § 435 lg 1: andmekogu põhimääruses sätestatakse /../ andmekogusse kogutavate andmete koosseis,

andmeandjad ja vajaduse korral muud ..

16 / 21

täidetakse eesmärke mõlema andmete koostöötlemisel, on mõistlik luua mõlema haldamiseks

üks infosüsteem koos kahe alamregistriga või muutes senise andmehalduse täielikult ümber,

koondades need muul viisil üheks.26 Selleks peab loomulikult olema selge vajadus ja põhjendus

ehk igapäevavajadus, mitte ajutine analüütiline eesmärk.

Kui ühildada soovitakse erinevate riiklike andmekogude andmeid, kus tegemist ei ole püsiva

vajadusega ja neid andmeid ei salvestata nö pikaajaliselt ja eesmärk on uus teadmus või analüüs,

võetakse selleks isikuandmete korral vastav luba (isikuandmete kaitse seadus, § 6).27

Ühekordsete andmete analüüsiks ja täiesti erinevate andmete kokku toomiseks ei pruugi olla

mõistlik ega vajalik asutada uut andmekogu, vaid see peakski käima teadustöö lubade raames

(ajutine eesmärk, andmed muutuvad igakordselt, samuti erinevad tulemuse analüüsiks kuluv

aeg ja ka töötlejad ehk läbiviijad).

Andmete statistilist vajadust kiirkorras ehk näiteks hädaolukorras, saab tagada läbi teiste

õiguslike võimaluste, näiteks läbi erisuste lubade kiiremaks menetluseks või muu erisusena

eriseaduses – näiteks nähes ette teatud olukorras selge õiguse ja erisuse andmeid saada või

pärida.28 Kui detailne on sellekohane normistik ja millised on asjakohased kaitsemeetmed,

sõltub kindlasti andmete tundlikkusest ning nende töötlemise eesmärgist.

Samuti võib avalikus sektoris rakendada Statistikaameti andmejagamisteenust29, kus

kombineeritakse nö asutuse teave muu teabega ja vastuseks saadakse statistiline teave.

Analüüside tegemiseks võib määratleda aga ka püsiva vajaduse korral konkreetsele asutusele

õiguse andmeid saada või juurdepääs pseudonüümitud andmete töötlemiseks30.

Arvestades kõiki võimalikke elulisi erisusi, ei ole võimalik anda käesolevas juhises

ammendavat ülevaadet kõikideks olukordadeks ning vajadus ja võimalused eeldavad igakordset

kaalumist ja põhjendamist.

26 Vt näiteks Terviseameti registrite ühildamist, uue nimega tervishoiukorralduse infosüsteem (tervishoiuteenuste

korraldamise seaduse muutmise ja sellega seonduvalt teiste seaduste muutmise seadus 569 SE),

https://www.riigikogu.ee/tegevus/eelnoud/eelnou/da9c1e85-b29b-437e-9aeb-c1bedc58bc1a 27 Isikuandmete kaitse seadus, § 6, https://www.riigiteataja.ee/akt/104012019011#para6, kooskõlas isikuandmete

kaitse üldmääruse artiklitega 5(1)(b) ja 89. 28 Ka Euroopa Liidu tasandil kavandatakse andmemäärusega luua eraldi õiguslik alus, küsida teatud erijuhtudel

andmeid. Vt viimase kohta ettepaneku 5.ndat peatükki: EUROOPA PARLAMENDI JA NÕUKOGU MÄÄRUS

ühtlustatud õigusnormide kohta, millega reguleeritakse õiglast juurdepääsu andmetele ja andmete kasutamist

(Andmemäärus), https://eur-lex.europa.eu/legal-content/ET/TXT/?uri=CELEX:52022PC0068. Vt ka tänaseid

erisusi hädaolukorras ülesannete määramisel, näiteks HOS § 14 lg 41,

https://www.riigiteataja.ee/akt/109082022024#para14 või ka erisust koostöö alusel, HKTS § 18 lg 2,

https://www.riigiteataja.ee/akt/117112021007#para18. 29 Riikliku statistika seadus, § 201, https://www.riigiteataja.ee/akt/111032022002#para20b1. 30 Vt nt sotsiaalseadustiku üldosa seaduse § 391, https://www.riigiteataja.ee/akt/106012023016#para39b1, mille

alusel on antud Sotsiaalministeeriumi analüüsi ja statistikaga tegeleval osakonnale õigus töödelda tervise-, töö-

ja sotsiaalvaldkonna poliitika kujundamiseks isikuandmeid, ilma et isik oleks otseselt tuvastatav.

17 / 21

2. Kokkuvõte andmelao reguleerimise vajalikkuse osas

Käesolevas juhises on toodud selgitused erinevate funktsionaalsuste kohta, mida andmeladu

võib täita. Kokkuvõttes leitakse, et kui andmeladu toetab andmekogu pidamist

andmekogule kehtivate reeglite kohaselt, siis seda eraldi andmekogu põhimääruses

reguleerida ei ole vaja, kuid põhimäärus peaks andma realistliku pildi andmekogus

toimuvast. Kindlasti ei tuleks seaduses tuua andmelao definitsiooni, mis ühest õiguslikku

sisu ei kanna. Andmeladu on vajalik eraldi reguleerida põhimääruses siis kui seoses

sellega soovitakse kehtestada mõni erisus - andmekogu muudest andmetest erinev

andmete vorm, erinev säilitamise tähtaeg, erinev turvaaste vms.

Loomulikult tagab suurem läbipaistvus ühtsed arusaamad andmetöötlusviisidest. Kehtestades

selgelt andmekogu põhimääruses näiteks, et analüüside tarvis peetakse pseudonüümitud või

anonüümitud kujul andmeladu, viitab vastutava töötleja hoolsuskohustusele

privaatsustehnoloogiate rakendamisel.31 Seega ei ole andmelao pidamine halb, vaid hea

lahendus, võimaldades töödelda andmeid viisil, kus isiku nimi või muud tuvastamist

võimaldavad andmed ei ole töötlusprotsessis nähtavad. Mida suurem on andmetöötluse

läbipaistvus, seda enam säilib inimeste usaldus digiriigi vastu. Kui andmeladu täidabki vaid

andmekogu peamisi eesmärke, puudub selle reguleerimise vajadus, sest pelgalt tehniliste

meetmete kirjeldamist ei saa selles eeldada. Eraldi reguleerimine on tarvilik kui selleks on

olemas õiguslik põhjendatus - erisuste loomisel muudest andmekogu reeglitest.

Lähtudes andmeladude eesmärkide kirjeldustest ja funktsionaalsuste selgitustest, ei piira

tehnoloogia andmetöötluse eesmärke – see milleks on andmeid lubatud kasutada, otsustab

üldise raamina seadusandja. Andmelao mõiste reguleerimine ei looks õigust või õigustust teha

midagi kindlal viisil, sest andmeladu võibki täita erinevaid funktsioone.

Kui soovida ühtseid põhimõtteid ja sellest juhisest tulevikus ei piisa, võib kaaluda

andmekogude pidamise sätete täiendamist AvTS-is (tuua selles näiteks peamised põhimõtted,

mida siis põhimäärustes kajastada).32 Need saaksid olla aga tõesti vaid põhimõtted mitte ühtse

andmelao kui sellise reguleerimine, sest funktsioonid võivad andmeladudel olla erinevad ja ka

sama funktsiooni võib täita muu nimetusega funktsionaalsuse kaudu. Põhimõttena võib kaaluda

seega nii arhitektuurilise osa õigusselgemaks tegemist (alamandmestike, alamregistrite jne

väljatoomise näol) või nähes ette kohustuse, kuna andmeladu või muu andmestike üksust eraldi

reguleerida tuleks ( nt andmete vorm, säilitamine vms).

Meelespea:

✓ Andmelao defineerimiseks seaduses puudub vajadus. Seda ei tule reguleerida ka

põhimääruses, kui tegemist on andmekogu ühe osaga ning kus andmeladu toetab

andmekogu pidamist ja mille tegevus lähtub andmekogu aluseks olevast seadusest

ja/või põhimäärusest.

✓ Kui andmeid soovitakse eraldi ühildada mitmest andmekogust, peab selleks olema

õiguslik alus. See ei seostu otseselt andmelao mõistega.

31 IKÜM art 5 ja 25. Minimaalsuspõhimõtte ja lõimitud ning vaikimisi andmekaitse põhimõtete rakendamine,

https://eur-lex.europa.eu/legal-content/ET/TXT/?uri=celex%3A32016R0679. 32 Näiteks AvTS § 435 lg 1 või selle alusel kavandatav volitusnorm.

18 / 21

3. Korduma kippuvad küsimused

Käesolevas jaos selgitatakse praktikas tõusetunud küsimusi. Kuna küsimused võivad ajas

muutuda, saab käesolevat juhist edaspidi ka nendega täiendada.

3.1. Kas andmelaost võib „teenindada“ teisi andmekogusid?

Jah võib. Nagu eelnevalt juhises selgitatud, siis on oluline see, millist funktsiooni see

andmeladu olemuslikult täidab. Tehnilises mõttes ei ole kuidagi piiratud seda, et kuidas või

läbi millise tehnilise funktsionaalsuse andmeid teistele andmekogudele edastatakse.

Oluline on vaid see, et tegemist on andmekoguga (ja ladu selle osa), mis on kohustatud andmeid

teisele riigi infosüsteemi kuuluvale andmekogule edastama.

3.2. Kas X-teel võib andmeid vahetada vaid riigi infosüsteemi kuuluvate

andmekogude vahel?

Eeldatakse, et võib ka laiemalt. X-tee on turvaline andmevahetuskanal ja selle kasutust tuleks

igal juhul toetada. See tähendab, et ka väljaspool riigi infosüsteemi kuuluvad andmekogud

võiks igal juhul kasutada andmete jagamisel turvalist kanalit. Eksitav on ilmselt sätte

asukoht seaduses, mille tõttu on seda vaid andmekogude kesksena tõlgendatud. Nimelt asub

säte AvTS-is andmekogude peatükis, kuigi sedastab konkreetses normis täiesti eraldiseisvana

õiguse, vahetada andmeid ka

teiste isikutega (AvTS § 439 lg

6).33

Eeltoodud tõlgendust, et X-tee ei ole mõeldud pelgalt riigi infosüsteemi kuuluvate

andmekogude vahel teabe vahetamiseks, selgitab ka 2015. a eelnõu seletuskiri34 järgmiselt:

Infosüsteemide andmevahetuskiht (X-tee) on õigusruumis reguleeritud kindlustava süsteemina,

mis on kohustuslik riigi infosüsteemi koosseisus olevate andmekogudele. See on loonud

õiguslikult olukorra, kus X-teed ei tohi kasutada andmekogudesse mitte puutuvas

andmevahetuses ning tuleb teha õigusruumi korrastamises valik, kas piirata X-tee kasutust

ainult selleks ette nähtud juhtudele või legaliseerida reaalne olukord. Näidetest tulenevalt on

otstarbekas legaliseerida X-tee kasutus moel, mis ei piira andmevahetust ainult andmekogude

33 AvTS § 439 lg 6, https://www.riigiteataja.ee/akt/110032022004#para43b9. 34 Riigikogu koduleht: Avaliku teabe seaduse muutmise ja sellega seonduvalt teiste seaduste muutmise seadus 71

SE, https://www.riigikogu.ee/tegevus/eelnoud/eelnou/c32e74a6-2903-4736-8513-d18358fc1ad3.

(5) Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja

riigi infosüsteemi kuuluvate andmekogude vahel toimub läbi riigi

infosüsteemi andmevahetuskihi.

(6) Käesoleva paragrahvi lõikes 5 toodu ei piira andmevahetust

infosüsteemide andmevahetuskihil muude juriidiliste isikute

vahel.

19 / 21

vahele, vaid võimaldaks X-teed kasutada ka avalikus sektoris jooksutatavate infosüsteemide

vahel ning samuti erasektoris.

Suurema õigusselguse huvides võiks tulevikustäiendada selles osas kas a) andmekogude

peatüki pealkirja (X-tee on rakendatav ka väljaspool seda peatükki) või b) tõsta eelviidatud säte

lõikest 6 seaduse teiste üldiste sätete alla (väljapoole andmekogude peatükki). Samas on normi

mõttena selle laiemat kasutusala eeldatud ning praktikas on sellest ka lähtutud.

3.3. Mis vahe on andmekogul ja infosüsteemil? Miks vormistada infosüsteemi

põhimäärus?

Sisuliselt võib see küsimus puudutada ka andmeladusid, mis on andmekogu osaks. Nimelt on

õigusruumis reguleeritud andmekogusid aga ka infosüsteeme, mille osaks andmekogud on.

Andmekogu on üks võrgu- ja infosüsteemi alamliik. Kõik andmekogud on võrgu- ja

infosüsteemid, aga kõik võrgu- ja infosüsteemid ei ole andmekogud.35 Seega toetab infosüsteem

andmekogu, need mõisted võivad ühtida kuid ei pruugi. Andmekogu haldust toetav infosüsteem

võimaldab määratleda kogu andmehalduse tervikuna. Infosüsteem toetab igal juhul

digitaalselt peetavat andmekogu, ilma selleta ei saaks andmekogu ehk andmete

hoiustamine funktsioneeridagi. Infosüsteemi ülesehituse, selle erinevate alamosade,

alamregistrite või andmestike reguleerimine aitab lihtsal viisil kaasa erinevate õiguste ja

kohustuste realiseerimisele. Seega ei ole infosüsteem pelgalt andmete hoidmiseks, vaid ka

nende töötlemise eesmärkide tagamiseks laiemalt – andmete kuvamiseks, edastamiseks, logide

ja juurdepääsude tagamiseks, kustutamiseks ja muudeks ülesanneteks – kõik see, mis on seoses

kogutud andmete haldamisega reguleeritud. Nii näiteks on võimalik tänu infosüsteemile tuua

ära selle erinevad osad, sest ka andmestikke, alamandmestikke või alamregistreid hallatakse

infosüsteemis. Tänu infosüsteemile on võimalik määrata erinevate osapoolte juurdepääsud ja

ulatus ning võimaldada täita näiteks ka erinevaid õigusi – esitada deklaratsioone, teha

tahteavaldusi, määrata kontaktisik või kontaktandmed jms. Ka andmete endi hoiustamiseks on

olemas infosüsteem, milles neid hoitakse. Nii ei ole digitaalse andmekogu eesmärgiks pelgalt

loetleda riigi infosüsteemi kuuluvate andmete koosseis, vaid näha ette ka nende haldusega

seotud õiguste ja kohustuste realiseerimine.

Infosüsteem on vajalik, et toetada seega kogutud andmete haldust (kasutust, jagamist,

säilitamist ja turvalisuse hoidmist). Õigusi ja kohustusi aitabki hallata ja määrata tehniline

süsteem andmete ümber. Kuigi sisuliselt võib ühe suure andmekogu õiguste halduses olla

rakendatud mitmeid (alam)infosüsteeme, siis õiguslikult moodustab kindla nimega süsteem ühe

ühtse terviku, s.t andmekogu ja selle haldamise – näiteks käsitletakse „tervise infosüsteemi“

puhul selle põhimääruses kogu õiguste ja kohustuste tervikut, mis on seotud sellesse kogutavate

andmetega (digilugu, pildipank, digiregistratuur, andmeladu). Kogu infosüsteemi hõlmav

regulatsioon (mille sees on eraldi süsteemid) loob suurema õigusselguse andmete kogumiga

toimuvast – kuidas neid komplekteeritakse, kellele edastatakse, kas neile on ka juurdepääs ja

kellel jms.

35 Võrgu- ja infosüsteemi mõiste tuleneb küberturvalisuse seadusest. Kui räägime infosüsteemidest, võiksime

seda mõistet silmas pidada.

20 / 21

3.4. Kas põhiandmeid võiks võtta ka teisest andmekogust, mitte sealt kus need

algselt tekivad?

Ennekõike peaks tõesti võtma aluseks teise riigi infosüsteemi kuuluva andmekogu andmed, kui

neid juba kogutakse.36 Näiteks on rahvastikuregister sellel eesmärgil loodudki andmeid

koguma, et oleks üks koht, kus andmete haldus on järjepidev ja andmete õigsus tagatud ning

mida saaksid aluseks võtta teised andmekogud oma andmete töötlemisel (näiteks isiku nimi ja

isikukood, et andmeid inimesega siduda ja teenuseid pakkuda). Rahvastikuregistri näitel on

andmetel ka õiguslik tähendus (sellise suure kaaluga on ka äriregister ja näiteks

kinnistusraamat). Loomulikult tuleb siinjuures arvestada aga ka erinevaid piiranguid, lähtudes

andmete esialgse kogumise eesmärgist ja andmete tundlikkusest, kus näiteks üheks

kaalukausiks laialdasel andmekasutusel võib olla andmete kogumise viis (näiteks mitte

haldusmenetluse käigus tekkiv teave vaid usaldussuhtest tekkiv teave).37 Eriseaduses tehtud

piirangud on erisused üldisest regulatsioonist ehk AvTS-i normidest.

3.5. Kas ühe andmekogu juurdepääsuhaldust saab kasutada ka teise andmekogu

juurdepääsuhalduse tagamiseks?

Küsimus võib seostuda ka andmeladudega, mis on andmekogu osaks ja mille kaudu võib

teenindada ka andmetele juurdepääse. Küsimus seisneb nimelt selles, kas ühe andmekogu

juurdepääsudeks loodud turvalist kanalit võib kasutada ka teise andmelao juurdepääsude

teenindamisel? Vastus on jah, kui tegemist on nn „karbitootega“ ehk standardlahendusega,

mida igaüks oma süsteemis andmekoguga liidestab ilma, et õigussuhted muutuks (keegi ei

halda kellegi eest ja nimel nö juurdepääsukanalit). Juurdepääsukanal peab olema lahutatud

turvanõuete jms kaudu erinevate andmekogude lõikes, sarnaselt laohoone ja selle ruumide

näitega - ehk sama ukse kaudu ei satutaks sinna, kuhu ei või sattuda.

Õige ei ole kasutada ühe andmekogu juurde loodud kanalit teise andmekogu teenindamiseks,

kui selleks puudub selge õiguslik alus (ühe andmekogu juurde kuuluvat funktsionaalsust

kasutatakse ka teise kohta sisenemiseks, sest sellisel juhult toimub õiguslikult ühe andmekogu

kaudu teise juurdepääsuhalduste teenindamine). Ristteenuste pakkumisel tuleks luua suurem

õigusselgus ja sätestadagi norm, mis viitab selgel sellele, et andmekogu (või andmelao)

juurdepääs tagatakse teise andmekogu(lao) kaudu (üle tuleks vaadata siis ka vastutava/volitatud

töötleja suhted ja põhjendada sellise lahenduse valikut).

36 AvTS § 436 lg 2, https://www.riigiteataja.ee/akt/110032022004#para43b6 37 Näiteks MKS § 29 toodud konkreetne ja kinnine loetelu isikutest, kellele andmeid jagada,

https://www.riigiteataja.ee/akt/129122022030#para29 või tervise infosüsteem, mille suur osa põhiandmetest

tekib arsti ja patsiendi usaldussuhtest ning mille töötlusest registris, ei saa pooled keelduda, TTKS § 592 lg 1,

https://www.riigiteataja.ee/akt/110102022004#para59b2.

21 / 21

3.6. Kas ühe andmekogu sees peavad andmed liikuma X-tee vahendusel - näiteks

andmete liigutamine andmekogu erinevate kihtide või operatiivbaasi ja lao

vahel?

Andmekogude siseselt ei pea andmed liikuma X-teel. Kui eesmärk on tagada suurem

läbipaistvus, siis seda saab tagada ka andmekogude logide pinnalt ilma, et selleks X-teed

kasutatakse. Kehtiv AvTS viitab täna selgelt, et kohustus X-teed kasutada kehtib andmekogude

vahelises suhtluses ja nendega seotud kolmanda osapoolega (teenused ehk andmevahetus

ettevõtetega). Kui seda põhimõtet soovitakse tulevikus muuta, tuleks ümber vaadata ka

andmekogudele (ja toetavatele süsteemidele) rakenduvad sätted.38

3.7. Mis on andmelao ja -järve vahe lihtsustatult?

Andmejärv on koht, kus on meeletus koguses andmeid, enamus andmed on seal mis iganes

kujul nad sinna saadeti või kuskil mujal talletati. Näiteks kui asutus A on teinud oma

infosüsteemi andmebaasi ja asutus B teinud täiesti teistsuguse infosüsteemi, siis nad mõlemad

võivad panna enda andmed andmejärve "ujuma". Andmed on seega andmejärves sellised, nagu

need olid A ja B infosüsteemides. Andmete suure erinevuse tõttu on andmejärv hea

masinõppeks, aga ei ole väga hea ärianalüütikaks. Kuigi vahel räägitakse ka andmejõest, siis

see on andmejärvega sarnane, lihtsalt selles on andmed lühiajaliselt või siis lisandub neid sinna

jooksvalt.

Andmeladu on aga koht, kuhu on talletatud andmed, mis on teatud põhimõtetele ja mudelitele

vastavalt juba struktureeritud. Eelmise näite jätkamiseks siis võiks asutuse A ja B andmed nüüd

olla andmelaos nii, et nad on omavahel võrreldavad - ehk sarnased andmed (näiteks

isikuandmed) on andmelaos sarnasel kujul, kui andmejärves oleksid nad erinevad. Andmeladu

on tihti eelduseks ärianalüütikaks, andmepõhiseks juhtimiseks, raportiteks jms.

38 Nt sätestab AvTS § 439 lg 5: Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja riigi infosüsteemi

kuuluvate andmekogude vahel toimub läbi riigi infosüsteemi andmevahetuskihi,

https://www.riigiteataja.ee/akt/110032022004#para43b9.

IT-Profiil (versioon: 3)

Sotsiaalministeeriumi valitsemisala riist- ja tarkvara ning e-teenuste üldine haldamise ja arendamise infotehnoloogiline profiil

Üldsätted

1. Infotehnoloogilise profiili (edaspidi IT profiili) eesmärgid on: 1. kirjeldada Tervise ja Heaolu Infosüsteemide Keskuse (edaspidi TEHIK) hallatava riist- ja tarkvara tüüpkonfiguratsioone ja nende

miinimumparameetreid; 2. haldus-, hooldus- ja koolituskulude vähendamine olemasolevale infosüsteemile; 3. tekkida võivate probleemide ja kulude minimeerimine läbi erinevate infosüsteemi osade integreerimise; 4. jätkuva arengu garanteerimine kõigile kasutatavatele infotehnoloogilistele (edaspidi IT) lahendustele Sotsiaalministeeriumi haldusalas; 5. kasutatava tarkvara ja riistvara ühtsuse saavutamine, mille abil on tsentraliseeritud hangete kaudu võimalik märkimisväärselt kokku hoida; 6. süsteemidele mõjuvate turvariskide minimeerimine; 7. tekitada süsteemide kasutajatele efektiivne, turvaline ja mugav töökeskkond;

2. Karbitoodete valikul ja implementeerimisel rakendada IT profiili võimalikult suurel mahul. IT profiilist kõrvalekalded on lubatud, kui need on möödapääsmatud ja TEHIK arhitektuurinõukogus kooskõlastatud;

3. IT profiili korrigeeritakse vastavalt vajadusele kuid mitte harvemini kui üks kord aastas. Muudetud IT profiil kinnitatakse TEHIK arhitektuurinõukogu poolt;

Tehnilised nõuded e-teenustele, lähtudes TEHIK'u hallatavatest infosüsteemidest ja infrastruktuurist

1. IT toodete ja komponentide valiku põhimõtted on: 1. sama funktsionaalsusega, kuid erinevate tootjate komponentide arv peab olema viidud miinimumini. Standard riistvara soetamisel

eelistada soovitavalt ühe tootja seadmeid, mis tagab kogu IT infrastruktuuri parema toimivuse ja seadmete ühilduvuse; 2. kõik valitud tooted peavad vastama kehtivatele standarditele, eelistada tuleb avatud standardeid; 3. testistaadiumis (beta, release candidate jne) tarkvara võib kasutada ainult testimise eesmärgil; 4. komponendid ja tooted peavad vastama asutuse poolt määratud turvareeglitele; 5. komponentide ja toodete, mis ei ole antud dokumendis kajastatud, kasutusele võtmine vajab eelnevat arhitektuurinõukogu heakskiitu;

Kehtib nii olemasolevate süsteemide uuendamise kui ka uute süsteemide loomise kohta (Applies to building brand new systems and also to refactoring existing systems)

Komponent

(Component)

Eelistatud

(Preferred)

Aktsepteeritav

(Acceptable)

Mitte valida

(Do not select) Kommentaarid

Kliendi kiht (Client Layer)

Lauaarvuti ja sülearvuti OS / keskkond (Desktop & laptop client OS / environment)

• Windows • Linux • macOS

Lauaarvuti ja sülearvuti kliendi kasutajaliides (Desktop & laptop client user interface)

• Chromium based • Firefox

• Safari (väline klient/external client)

• Edge Legacy • Internet Explorer

Mobiilse kliendi OS / keskkond (Mobile client OS / environment)

• Android perekond (Android family)

• iOS • Windows Phone

Mobiilse kliendi kasutajaliides (Mobile client user interface)

• Chromium based • Firefox • Safari

• Multi platform frameworks

o Flutter o Kotlin

Multiplatform • Native app

• Multi platform frameworks

o .Net based o Nativescript o Ionic

Esitluskiht (Presentation Layer)

Sisuhaldussüsteem (Content management system)

• Drupal • Strapi[1] • WikiJS[1]

• Joomla! • WordPress

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Esitluskihi raamistik (Presentation framework (View))

• JavaScript o Angular o React

• JavaScript o Next.JS[1] o Single-SPA o Web-pack

• Java o JSP o JSF

• iFrame • Microsoft .Net • Python

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Veebiserver (Web server) • Nginx

• Apache HTTP server

• Microsoft IIS

IT-Profiil (versioon: 3)

Funktsionaalne testimine (Functional testing)

• Selenium • Selenide

• Cypress[1] • Playwright[1]

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Rakenduskiht (Application Layer)

Rakenduse raamistik (Application framework)

• Java o Spring[1] o Spring boot

• Java o Quarkus[2]

• Java o Micronaut

• C# o .Net o .Net

Framework o ASP.NET o Entity

Framework Core

[1] Kogu Springi perekond (All Spring family)

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Protsessimootor (Workflow Engine)

• Zeebe

Andmeloogika (Persistence framework)

• Java o JPA o JDBCTemplate

• Java o Hibernate[1] o jOOQ

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Otsingumootori indeks (Search Engine Index)

• Elasticsearch

Integratsioon (External integration (integration to other systems))

• AMQP[1] • REST

• GraphQL[2] • gRPC[2] • SOAP

• Oracle Advanced Queuing

[1] RabbitMQ

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Andmete laadimine (Data Loading - ETL)

• Apache Hop • OData consumer [1]

• Meltano[2] • Pentaho[2]

[1] TEHIKu toode (TEHIK's product)

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Aplikatsiooniserver (Application server)

• Java o Tomcat o Embedded

▪ Jetty ▪ Tomcat ▪ WildFly

o GraalVM

• Java o WildFly [1]

• Webmethods Integration Server

• .NET o MS IIS

• Java o Apache

JServ o Sun Java

System Application Server

o SAP o IBM

WebSphere o Oracle iAS o Oracle

iPlanet Web Server

o WebLogic

[1] VM põhine (VM based)

Funktsionaalne testimine (Functional testing)

• Insomnia • SoapUI

• Postman

Koormustestimine (Load testing)

• Jmeter • Gatling

• Testkube

Andmekiht (Persistence Layer / Database layer)

Andmebaasi migratsioon (Database migration)

• Liquibase • Flyway

Relatsiooniline andmebaas (Relational DBMS)

• PostgreSQL • MariaDB[1] • MS SQL Server • Oracle DB • Sybase

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

IT-Profiil (versioon: 3)

Mitte ainult SQL (NoSQL) • KeyDB

• MongoDB[1] • Valkey[2]

• Redis

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

[2] https://valkey.io/

Andmeladu (Data Warehouse)

• Vertica • Sybase IQ

Andmete replikatsioon (Data Replication)

• Spilo

Failide hoiustamine (Object Storage)

• MinIO • S3 protokollil

põhinevad objektihoidlad

• Failid andmebaasis (BLOB)

Infrastruktuuri kiht (Infrastructure Layer)

Directory services • MS Active Directory

Autentimine ja Ühekordne

sisselogimine (Authentication

and Single Sign On)

• GovSSO • TEHIK SSO[1]

[1] TEHIK SSO on asutuseväliste kasutajate vaates liikumas toe lõppemise suunas. (TEHIK SSO is moving towards end of life)

Kasutajaõiguste haldus (Authorization)

• Pääsuke [1] • TEHIK SSO AD realm[2]

• TEHIK SSO + rollide api teenuse pool[3]

• MS AD (siseteenused)

[1] https://www.ria.ee/riigi- infosusteem/kesksed- platvormid-avalike-e-teenuste- pakkumiseks/paasuke

[2] On mõeldud siseste kasutajate rollide jaoks (Is ment for inside user rolls)

[3] TEHIK SSO on asutuseväliste kasutajate vaates liikumas toe lõppemise suunas. (TEHIK SSO for external users is moving towards end of life)

Identiteedi haldus (Identity management)

• MIM[1]

[1] Tootel on saabumas eluea lõpp (Product is moving towards end of life): https://learn.microsoft.com/en- us/lifecycle/products/microsoft- identity-manager-2016

Logihaldus (Log management)

• Elastic Agent/Elastic Beats/Logstash

• rsyslog

• GreyLog • Windows Event

Collector

Süsteemi haldamine ja järelevalve (System management and monitoring)

• Prometheus • Grafana • Elastic APM

• Zabbix • Nagios

Koormusjaotur (Traffic management)

• Nginx • HAProxy

Puhverdamine (Caching) • Nginx

• Squid • Varnish

Tööde ajastamine (Job scheduling)

• Application specific decision ie Quartz or cron, windows scheduler

• k8s CronJob

Serveri operatsioonisüsteem (Server OS)

• Linux (Tootja poolt viimane pikaajalise toega või stabiilne versioon)

o Oracle Linux o RedHat o Ubuntu

• Windows o MS (64 bit)

• Linux o Debian o CentOS

• IBM AIX • Other UNIXs

IT-Profiil (versioon: 3)

Konteinerid (Containers) • OCI compliant[1] [1] https://opencontainers.org

Konteinerite orkestreerimine (Contaier orchestration)

• Kubernetes • Docker Swarm

Virtualiseerimine (Virtualization)

• VmWare

• Hyper-V • QEMU/KVM • OracleVM • Xen

Serveri riistvara (Server hardware)

• x86_64 • RISC

Varundamine (Backup)

• VmWare o Veritas

Netbackup • Kubernetes

o S3

• Symantec Backup

Exec

Kettakasti riistvara (Storage hardware)

• SAN o FC >= 32 Gb/s

• SAN o FC >= 16 Gb/s

• iSCSI

Riistvaraline krüptomoodul (HSM - Hardware security module)

• Thales • Utimaco

Tulemüür (Firewall)

• DPI (Deep packet inspection) Layer 7 Pahavara tõrje (Anti- malware)

Muud aspektid (Other Aspects)

Programmeerimiskeeled (Programming languages)

• Java • TypeScript

• Go[1] • JavaScript • Kotlin[1] • Python[1] • PHP[1] • Rust[1][2]

• NET • C/C++/C# • Webmethods flow • iWay Functional

Language

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

[2] Krüptograafiliste tegevuste teostamiseks (To perform cryptographic activities)

Java virtuaalmasina implementatsioon (Java vitual machine implemetation)

• OpenJDK • Oracle JDK

Versioonihaldus (Version control system)

• GitLab o Koodivaramu[1] o TEHIK

haldusalas olev

• GitHub[1] • SVN • Atlassian Bitbucket

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Artefaktide repositoorium (Artifacts repository)

• JFrog artifactory • Gitlab registry

• DockerHub[1] • GitHub Packages[1] • npmjs.com[1]

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Pidev integratsioon (Continuous integration)

• Gitlab CI • Github Actions[1] • Jenkins • Bamboo

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Paigalduse automaatika (Continious Deployment / Delivery)

• Ansible • GitLab CD (dev/test) • Helm (live) • Terraform

• GitHub Actions[1] • Argo CD[1]

• Jenkins • Bamboo

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Lähtekoodi analüüs (Code analysis)

• SonarQube

Tarkvara materjalide loend (SBOM - software bill of materials)

• CycloneDX SBOM

Tarkvara materjalide loendi analüsaator

• Dependency-Track[1] [1] https://dependencytrack.org

IT-Profiil (versioon: 3)

(software bill of materials analysis platform)

Analüütika (Analytics) • Tableau • Apache Superset[1]

• Webfocus • Qlik Sense • Oracle BI Publisher • SAP® Business

Objects

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Serverid

1. Riistvara standard 1. X86-64 platvorm 2. Dubleeritud komponendid (toiteplokid, ventilaatorid jms.) 3. Kuumvahetatavad kettad 4. Kaughaldusliidese olemasolu koos vajalike funktsioonide litsentseeritusega (irdmeedia tugi jms.), kaughaldusliides peab toimima

modernsete veebilehitsejatega ilma java/flash toeta) 5. Ostetaval riistvaral peab võimalusel olema vähemalt kaks teineteisest sõltumatut (st. ei tohi olla sama firma/grupi koosseisus) volitatud

hooldus/garantiiteenuse pakkujat 6. Riistvara ostetakse reeglina kolme aastase NBD toega koos nõudega, et kriitiliste varuosade vaheladu peab olema Eestis kohapeal.

Sisukord Sissejuhatus 1 - Seotud dokumendid ja täiendav materjal (Confluence) 2 - STEEL TERK andmeaida komponentide vaade

CI/CD Platform ja käivitused Andmeallikad VERTICA STEEL andmeait Andmehaldus ja jälgimine

3 - Andmelaadimiste töövoog Tegevussammude sisukirjeldus

ODS DDL rakendamine SAP -> ODS andmelaadimised dbt transformatsioonid

4 - Andmevoog ja kihiline arhitektuur STEEL TERK andmeaidas Andmevoog tervikuna ODS – Operatiivandmete koopia EDW – Ärimudel Verticas DWH – Aruandluse kiht

5 - Keskkondade loogika STEEL TERK andmeplatvormil Git–CI/CD loogika ja konteinerite ehitamine

Arenduse töövoog Test-keskkonna CI/CD Live-keskkonna CI/CD

Kubernetes ja keskkondade eraldatus Vertica keskkonnad ja skeemid

Arenduse skeemid Verticas Test-keskkonna skeemid Verticas Live-keskkond Verticas

SAP HANA allikad test- ja live-keskkondades

Sissejuhatus STEEL TERK andmeplatvorm on Tervisekassa (TERK) andmelao tehniline tuumik, mis koondab SAP HANA allikatest pärinevad operatiivandmed ühtsesse, standardiseeritud ja versiooneeritud

andmehoidlasse. Platvormi eesmärk on pakkuda usaldusväärset, korduvkasutatavat ja hästi hallatud andmebaasi, mis toetab nii aruandlust, analüüsi kui ka edasist äriloogika arendamist.

Käesolev dokument kirjeldab STEEL TERK andmelao arhitektuuri, tehnilisi komponente, keskkondade loogikat, laadimiste ja transformatsioonide protsesse ning CI/CD toimimist. Fookus on tehnilistel mehhanismidel – kuidas andmed liiguvad SAP süsteemidest ODS kihti, edasi EDW mudelitesse ning lõpuks DWH aruandluskihile; kuidas Kestra, Kubernetes, dbt, Apache Hop ja Liquibase koos töötavad; ning kuidas arendus-, test- ja live-keskkonnad on üles ehitatud.

Dokument ei dubleeri eraldi Confluence’i dokumentatsiooni, mis katab detailsemalt andmekonversioone, õiguste haldust, testimist ja ärimõisteid. Need on viidatud eraldi peatükis ning integreeritud temaatiliste osade alla.

1 - Seotud dokumendid ja täiendav materjal (Confluence)

Andmekonversioonid Allikas -> ODS Andmelao õiguste maatriks Andmelao testimise plaan Andmelao ärisõnastik dbt kasutusloogika Projekti nõuded

2 - STEEL TERK andmeaida komponentide vaade Eesmärk: Kirjeldada STEEL TERK andmeplatformi ehitusel kasutatavaid komponente, nende eesmärke ning kasutust Koostaja: Andres Kukk (mailto:[email protected]) Kuupäev: 2025-11-24

CI / CD

Tarbijad

Andmehaldus ja jälgimine

VERTICA STEEL andmeait

ANDMEALLIKAD

Platform / Käivitused

VERTICA STEEL ärimudel

ODS

dbt docs serve

PodCreate ajastatud

PodCreate ajastatud

PodCreate ajastatud

Logid

Logid

Logid

Alertid

model build

model build

secrets

secrets

secrets

connection and pod konfiguratsioon

connection and pod konfiguratsioon

profiles.yml/env

Load

Extract

Extract

Extract

Update

push image pull image

pull image

Kubernetes HOP loader pod'id

Kubernetes DBT runner pod'id

Kubernetes Liquibase runner pod'id

Kestra Pod

Container Registry

Secrets

ConfigMaps

SAP HANA - CRT

SAP HANA - ERT

SAP HANA - DRT

Vertica DW_STEEL_*_ODS skeemad

Vertica DW_EDW skeema

Vertica DW_DWH skeema

Andmekataloog ja lineage (dbt docs)

Monitooring & teavitused

BI tööriistad (Power BI)

Analüütikud

Git Repos (dbt, Hop, Liquibase)

CI Pipelines\n(unit, dbt build, image build)

CI/CD Projektis kasutatavad git repod

Liquibase - kasutusel DDL haldamiseks ODS kihi tabelite jaoks. Igale alliksüsteemile vastavad andmed hoitakse ODS kihi eraldi skeemas. Vastavalt allikatele/ODS-skeemadele on jagatud ka DDL kood kolme repo vahel:

https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dw_steel_crm_ods_ddl https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dw_steel_herp_ods_ddl https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dw_steel_derp_ods_ddl CI töövoo käigus ehitatakse liquibase töö-image'd mis sisaldavad DDL koodi ning Liquibase changelog'i. Töö-image laaditakse TEHIKU image-registrisse registry.tehik.ee/dwh/domains/tis/steel

Apache Hop - kasutusel andmete pärimiseks alliksüsteemidest ning nende kirjutamiseks STEEL andmeaita (extract-load). Igale alliksüsteemile vastavad andmed hoitakse ODS kihi eraldi skeemas. Vastavalt allikatele/ODS-skeemadele on jagatud ka DDL kood kolme repo vahel:

https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dw_steel_crm_ods https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dw_steel_herp_ods https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dw_steel_derp_ods CI töövoo käigus ehitatakse hop-loader image'd mis sisaldavad kasutatavat Apache Hop koodi (asukohas /files ja /files/hop-loader-helpers ) ning laadimisel kasutatavat SQL koodi (extract-päringud, STG-ODS laadimised; alamkaustas /files/ODS/ ).

Dbt - kasutusel on kolm dbt repot. dbt central - https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dbt-central

repo on kasutusel selleks, et liidestada omavahel järgnevad child-repod ( dbt deps ). Selle repo sees ei ole hetkel mudelite koodi. Siin võib hoida keskset haldust nõudvat osa dbt koodist - näiteks testid, macrod mida peab saama kasutada kõikides child-repodes ning mida ei ole mõistlik igas child-repos eraldi hallata. CI töövoo käigus ehitatakse selle repo baasilt dbt-runner image. Image sisaldab ainult dbt-central repos sisalduvat koodi ning dbt konfiguratsiooni template'i. Child repod mapitakse konteineri külge gitist run- time'l.

EDW_STEEL - https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/edw_steel repo sisaldab dbt koodi EDW_STEEL skeema tarbeks. Kood asub alamkatalogis /files/terk-steel

/snapshots - kood andmeajaloo säilitamiseks andmeaidas dbt snapshot funktsionaalsuse abil. See on transformatsiooni-ahela esimene samm kõikide ODS tabelite tarbeks. /models/base - kood aruandluseks vajalike andmete selekteerimise sammu tarbeks. /models/core - kood transformatsiooni-ahela vahesammude tarbeks. /models/final - kood transformatsiooniahela lõppsammude tarbeks (veergude ja tabelinimede tõlkimine ärikasutuse keelde) /seeds - csv failid aruandluseks vajaliku lisasisendi laadimiseks andmeaita (EI OLE KASUTUSEL)

DWH_STEEL - https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/dwh_steel repo sisaldab dbt koodi DWH_STEEL skeema tarbeks. Kood asub alamkataloogis /files/terk-steel

Kestra https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/kestra - repo sisaldab DDLi, HOP laadimiste ning dbt transformatsioonide käivituseks mõeldud Kestra flow'de koodi. Samuti laadimiste järjestuse loogikat, käivituste ajastamist ning teavituste haldamise käske Kestra tarbeks.

Kubernetes https://gitlab.sotsiaalministeerium.ee/dwh/domains/tis/steel/kubernetes - repo sisaldab secrets.yaml ning configmaps.yaml failide template'i. Need on kasutusel Liquibase, Hop ning dbt podide seadistuste ning saladuste haldamisel.

Platform ja käivitused STEEL andmeplatvorm töötab Kubernetesel, kus iga tööülesanne on eraldi konteineripõhine käivitusüksus (ephemeral pod). Kestra vastutab kõikide laadimiste, transformatsioonide ja DDL muudatuste ajastamise ja orkestreerimise eest. Diagrammil nähtavad PodCreate nooled tähistavad seda, et Kestra loob HOP-i, Liquibase’i ja dbt podid vastavalt laadimisgraafikule või käsitsi käivitustele.

HOP-loader podid tegelevad SAP HANA allikate (CRT, DRT, ERT) päringute tegemisega ja andmete laadimisega ODS-skeemidesse. Liquibase podid haldavad ODS-kihi tabelite versioone ja muudatusi. Dbt runner podid tegelevad ärimudeli loomisega – ODS → EDW → DWH transformatsioonid leiavad aset mudelite ehitamise (dbt build) käigus.

Kõik podid tõmbavad oma image’d image-registrist, mis tagab, et kasutusel on see versioon, mille CI pipeline on tootnud. Saladused tulevad Kubernetese secrets'itest ning ühendused ja käivitusseaded ConfigMap’idest. Logid suunatakse monitooringusüsteemi, kust saadakse ka teavitused tõrgete korral.

Andmeallikad Diagrammil kujutatud SAP HANA allikad – CRT, DRT ja ERT – on STEEL platvormi esmased sisendtarnijad. Need süsteemid sisaldavad operatiiv-andmeid, mida laaditakse andmeaita muutumatul kujul (tabel allikas ning vastav allikas STEEL andmelao ODS skeemas peaks olema sama andmekoosseisuga). HOP-loader pod’id teevad extracte HANA tabelitest, kasutades ConfigMap’ides määratud ühendusi ja secretist saadavaid ühemduse andmeid. Iga allikas laaditakse talle vastavasse ODS-skeemasse, mis hoiab allikapõhise eristuse selgelt paigas.

VERTICA STEEL andmeait STEEL andmeait on üles ehitatud kolmekihilisena – ODS, EDW ja DWH. ODS hoiab allikatest tulnud andmed muutmata kujul. Liquibase pod’id hoiavad ODS-i tabelid nõuetekohasel kujul, HOP pod’id laadivad sinna andmed. EDW kiht on kasutusel äriloogika rakendamiseks ja DWH kiht andmete presenteerimiseks ning kasutamiseks.

Dbt runner pod’id ehitavad mudelid ODS-ist EDW-sse ja sealt edasi DWH-sse (“model build” joonisel). EDW-st saab alguse transformeeritud, tehniliselt korrastatud andmevaade. DWH on seevastu kasutajatele mõeldud tõlgitud ärikiht, millele toetuvad nii BI kui analüütikud.

Andmehaldus ja jälgimine Diagrammil on eraldi välja toodud andmekataloog ja lineage (dbt docs) ning monitooring – need on platvormi läbivad tugiteenused.

Dbt-l põhinev dokumentatsioon tekib CI töövoos (dbt docs generate) ning teenindatakse CI kaudu (“dbt docs serve”). See tagab, et mudelite kirjeldus ja lineage on alati versioonikontrolli seisuga kooskõlas. Andmekataloog näitab, mis mudelid on STEEL andmeaidas ja kuidas need üksteisest sõltuvad (data lineage) samuti hoitakse seal ärilist kirjeldust objektide tähenduse kohta.

Monitooring kogub logisid HOP-, dbt- ja Liquibase-podidelt (diagrammil näha punktiirnooled). Kestra saadab teavitusi laadimiste ja transformatsioonide seisu kohta ka andmeaida halduse e-mailidele ja või webhookidele.

3 - Andmelaadimiste töövoog Eesmärk: Kirjeldada andmelaadimiste ning transformatsioonide käigus tehtavaid tegevussamme kasutatava tehnise seadistuse kontekstis. Koostaja: Andres Kukk (mailto:[email protected]) Kuupäev: 2025-11-24

Vertica_DWH_STEELVertica_EDW_STEELdbt_Runner_PodVertica_DW_STEEL_(CRM|DERP|HERP)_ODSHop_Loader_PodLiquibase_PodKestra_FlowK8s nimeruum: tis-steelSAP HANA: SAP_ERTSAP HANA: SAP_DRTSAP HANA: SAP_CRT

Vertica_DWH_STEELVertica_EDW_STEELdbt_Runner_PodVertica_DW_STEEL_(CRM|DERP|HERP)_ODSHop_Loader_PodLiquibase_PodKestra_FlowK8s nimeruum: tis-steelSAP HANA: SAP_ERTSAP HANA: SAP_DRTSAP HANA: SAP_CRT

Startib Liquibase pod'i 1

configMap + secrets 2

DDL lisanduste ja muudatuste rakendamine CRM ODS skeemas 3

staatuse tagastus (success / failure) 4

logide tagastus 5

DDL lisanduste ja muudatuste rakendamine HERP ODS skeemas 6

staatuse tagastus (success / failure) 7

logide tagastus 8

DDL lisanduste ja muudatuste rakendamine DERP ODS skeemas 9

staatuse tagastus (success / failure) 10

logide tagastus 11

Stardib Hop loader pod'id 12

configMap + secrets 13

andmepäring CRT tabelitest 14

laadimine CRM STG_* tabelitesse 15

transf ning laadimine CRM STG -> ODS tabelitesse 16

staatuse tagastus (success / failure) 17

logide tagastus 18

andmepäring DRT tabelitest 19

laadimine DERP STG_* tabelitesse 20

transf ning laadimine DERP STG -> ODS tabelitesse 21

staatuse tagastus (success / failure) 22

logide tagastus 23

andmepäring ERT tabelitest 24

laadimine HERP STG_* tabelitesse 25

transf ning laadimine HERP STG -> ODS tabelitesse 26

staatuse tagastus (success / failure) 27

logide tagastus 28

start dbt pod (dbt build) 29

configMap + secrets 30

loeb ODS (kõik allikad) 31

build SNAPSHOT_*, BASE_*, CORE_*, FINAL_* + tests 32

build analüütiline mudel 33

staatuse tagastus (success / failure) 34

logide tagastus 35

VÄRVID JOONISEL

Märge Kirjeldus

ODS DDL rakendamine

SAP → ODS andmelaadimised

dbt transformatsioonid

Tegevussammude sisukirjeldus:

ODS DDL rakendamine

1. Liquibase podid ehitatakse allikapõhistelt liquibase-imagetelt. Need ehitatakse vastava repo CI töövoo käigus ning sisaldavad ODS kihi ddl koodi. Iga allikapõhise ODS-skeema loomiseks/muutmiseks luuakse eraldi Liquibase-pod (ephemeral) mis pärast täitmist sulgetakse. Käivituste järjestust ning paralleelsust hallatakse Kestra töövoo (flow) tasemel. Koodi hoitakse järgnevates repodes:

repo: /tis/steel/kestra repo: /tis/steel/dw_steel_crm_ods_ddl repo: /tis/steel/dw_steel_herp_ods_ddl repo: /tis/steel/dw_steel_derp_ods_ddl

2. K8s configMaps ning secrets failid on kasutusel Liquibase-pod'ide seadistuste ning ligipääsude juhtimiseks. Vastavate failide struktuur asub repos:

repo: /tis/steel/kubernetes configmap/secrets: dw-steel-crm-ods-ddl configmap/secrets: dw-steel-herp-ods-ddl configmap/secrets: dw-steel-derp-ods-ddl

3. Liquibase loob/ning muudab ODS skeemade objektid vastavalt ddl sisendile. Logib muudatused. 4. Liquibase käivituse staatust ning logi edastatakse Kestrasse (pikemaajalist logide säilitamist siin

ei toimu) 5. Liquibase käivituse staatus ning logi kogutakse kesksesse logirakendusse otse podidelt.

SAP -> ODS andmelaadimised

1. Hop podid ehitatakse allikapõhistelt hop-imagetelt. Need ehitatakse vastava repo CI töövoo käigus ning sisaldavad allika tabeli/vaatepõhiseid päringuid ning stg->ods loogikat. Iga tabeli laadimiseks luuakse eraldi Hop-pod (ephemeral) mis pärast laadimise lõppemist sulgetakse. Laadimiste järjestust ning paralleelsust hallatakse Kestra töövoo (flow) tasemel. Koodi hoitakse järgnevates repodes:

repo: /tis/steel/kestra repo: /tis/steel/dw_steel_crm_ods repo: /tis/steel/dw_steel_herp_ods repo: /tis/steel/dw_steel_derp_ods

2. K8s configMaps ning secrets failid on kasutusel hop-pod'ide seadistuste ning ligipääsude juhtimiseks. Vastavate failide struktuur asub repos:

repo: /tis/steel/kubernetes configmap: hop-loader-config-crm configmap: hop-loader-config-herp configmap: hop-loader-config-derp secrets: hop-loader-secrets-crm secrets: hop-loader-secrets-herp secrets: hop-loader-secrets-derp

3. Andmelaadimised allikatest STEEL andmeaida ODS skeemadesse (allikapõhised):

laadimised toimuvad copy stream põhimõttel kõikide tabelite tarbeks on seadistatud ka inkrementaalse laadimise valmisolek. Regulaarsel laadimisel on see kasutusel ainult tabelite tarbeks millel on olemas primaarvõti ning ajatempel mille abil delta-laadimist juhtida. Inkrementaal-/täislaadimised on eristatud Kestra flow tasemel.

4. Laadimise staatust ning logi edastatakse Kestrasse (pikemaajalist logide säilitamist siin ei toimu) 5. Laadimiste staatus ning logi kogutakse kesksesse logirakendusse otse podidelt.

dbt transformatsioonid

1. Hop laadimiste lõppemisel käivitab kestra dbt pod'i. See ehitatakse /tis/steel/dbt-central repo CI töövoos.

repo: /tis/steel/dbt-central - sisaldab ainult keskset haldamist vajavaid osi dbt loogikast (testid, macrod jmt). child-repo: /tis/steel/edw-steel - sisaldab dbt mudeleid EDW kihi kohta. Mapitakse gitist runtime'l. child-repo: /tis/steel/dwh-steel - sisaldab dbt mudeleid DWH kihi kohta. Mapitakse gitist runtime'l.

2. dbt käivitatakse build käsuga mis käivitab sõltuva jadana dbt testid, snapshotid, model'id. 3. dbt käivituse staatust ning logi edastatakse Kestrasse (pikemaajalist logide säilitamist siin ei

toimu) 4. dbt käivituse staatus ning logi kogutakse kesksesse logirakendusse otse podidelt.

4 - Andmevoog ja kihiline arhitektuur STEEL TERK andmeaidas

Eesmärk: Kirjeldada andmeaida kihilist arhitektuuri ning kirjeldada andmeaida kihtide sisu ning eesmärke. Koostaja: Andres Kukk (mailto:[email protected]) Kuupäev: 2025-11-25

STEEL TERK andmeaida arhitektuur on üles ehitatud kolmekihilise mudelina. Kihid ja nende rollid:

ODS (operatiivandmete koopia), EDW (ärimudel Verticas) ja DWH (aruandluse kiht).

Diagramm kirjeldab, kuidas andmed liiguvad allikasüsteemidest läbi erinevate transformatsioonisammude kuni lõppkasutajani.

Kiht: DWH (aruandlus)

Kiht: EDW (ärimudel Verticas)

Kiht: ODS (allika koopiad) ODS skeemid

Allikatabelite koopiad HANA -> Vertica tüübitõlge

Tehnilised veerud

Skeema: DW_STEEL_CRM_ODS

STG_* abitabelid ODS tabelid (allika

nimedega) load - laadimise

monitooring

Skeema: DW_STEEL_DERP_ODS

STG_* abitabelid ODS tabelid (allika

nimedega) load - laadimise

monitooring

Skeema: DW_STEEL_HERP_ODS

STG_* abitabelid ODS tabelid (allika

nimedega) load - laadimise

monitooring

Alamkiht: SNAPSHOT dbt snapshot

andmemuudatuste ajaloo hoidmine

materjaliseeritud tabelitena

Alamkiht: BASE snapshot_BASE vaated vajalike veergude valik vajaliku ajaloolise seisu

valik vaikimisi vaated

Alamkiht: CORE nimetused sarnased SAP

BW mudeliga migreeritud BW loogika

allikaandmete ühendamine vaikimisi vaated

Alamkiht: FINAL *_final tabelid

materjaliseeritud tabelitena

ainult DWH-sse eksponeeritavad objektid

eelistatult inkrementaalsed

Skeema: DWH_STEEL aruandluse vaated

1:1 peegeldused FINAL kihi objektidest

Andmevoog tervikuna Diagaramil kujutatud nooled kirjeldavad ühesuunalist andmeteed:

1. ODS skeemid → EDW SNAPSHOT 2. SNAPSHOT → BASE 3. BASE → CORE 4. CORE → FINAL 5. FINAL → DWH

See ülesehitus tagab:

selge vastutusjaotuse (allika koopia, transformatsioon, eksponeerimine), auditeeritava andme-lineage’i, standardiseeritud andmemudeli, mis toetab usaldusväärset aruandlust ja analüüsi.

ODS – Operatiivandmete koopia ODS kiht on tehniline puhver SAP HANA (tulevikus võib allikaid lisanduda) allikate ja ülejäänud andmeplatvormi vahel. Siin hoitakse allikatabelite võimalikult üks-ühele koopiad koos vajalike tehniliste rikastustega. Sel kihil toimub:

andmetüüpide ühtlustamine HANA → Vertica vormingute vahel, tehniliste veergude lisamine, tabelite laadimise monitooring selleks tarbeks load tabelid kõikides ODS kihi skeemades.

ODS kiht koosneb alliksüsteemi põhiselt loodud skeemadest. Hetkeseisuga kuulub sinna kolm skeemat — DW_STEEL_CRM_ODS, DW_STEEL_DERP_ODS ja DW_STEEL_HERP_ODS. Igas skeemas on STG_* laadimise abitabelid ja ODS tabelid, mis kasutavad allikaga sama nimekuju. ODS on ühtlasi lähtepunkt EDW kihi SNAPSHOT alamkihile.

STG_ tabelid on kasutusel ainult laadimiste juhtimiseks. Eduka laadimise lõpus need tühjendatakse. Laadimise vea korral STG_ -> ODS sammus jääb STG_ tabelitesse ebaõnnestunud laadimise delta. Seda saab kasutada veaotsingul.

ODS kihti kuuluvad tabelid peaksid 1:1 vastama allikale. Vastavad peavad olema ridade arv, veergude arv kui väljade sisu. Ainsad muudatused võrreldes allikaga:

veerunimekujude muutmine vastavaks Vertica baasi reeglitele - nt kaldkriipsud tabeli ning veerunimedes on asendatud alakriipsudega lisatud on laadimiste metaandmete veerud mis näitavad rea andmeaita jõudmise kuupäeva ning laadimisprotsessi id'd. tehtud on andmetüübiteisendused allikas vs sihtbaas.

EDW – Ärimudel Verticas EDW kiht moodustab andmehoidla keskse äriloogilise mudeli. Kihil on neli alamkihti, millest igaüks täidab kindla etapi andmetöötlus-ahelas:

SNAPSHOT – säilitab ajaloolised andmemuudatused dbt snapshot mehhanismiga; tulemusena tekivad materjaliseeritud versiooni-tabelid (SCD) iga allikast laaditud tabeli kohta. Kuna ODS on allika täpne koopia siis tekitatakse muudatuste ajalugu SNAPSHOT-alamkihis. ETTEVAATUST: tegevused SNAPSHOT kihis võivad tekitada püsivat andmekadu!

BASE – valib vajalikud veerud ja ajaloolise seisu ning loob alusteabe EDW mudelile; koosneb andmebaasi vaadetest. Sisulisi andmeteisendusi siin ei tehta. CORE – migreeritud SAP BW loogika ning vastavalt TERK analüütikute sisendile tehtud muudatused selles, ühendab allikad ja annab mudelile ärilise struktuuri; äriloogika rakendmine toimub siin kihis; vaikimisi implementeeritud andmebaasi-vaadetena. FINAL – lõplikud materjaliseeritud tabelid, mis on mõeldud DWH kihi eksponeerimiseks; eelistatult inkrementaalsed mudelid. Iga objekt mida peegeldatakse DWH kihti peaks EDW kihis omama FINAL-kihi tabelit. SAP BW tabelite ning veergude tõlkimine ärikeelde toimub siin kihis (1:1 migreeritavate objektide korral)

Andmevoog liigub alamkihtide vahel sirgjooneliselt: SNAPSHOT → BASE → CORE → FINAL.

DWH – Aruandluse kiht DWH kiht on kasutajatele eksponeeritav aruandluskiht. Skeema DWH_STEEL sisaldab:

aruandluse vaateid - 1:1 peegeldusi EDW FINAL mudelitest, vormi ja keelestandardit, mis sobib BI tööriistadele ja analüütikutele.

DWH kiht ei sisalda täiendavat äriloogikat – see on EDW FINAL-objektide esitluskiht.

5 - Keskkondade loogika STEEL TERK andmeplatvormil STEEL andmeplatvorm kasutab kaheetapilist keskkonnamudelit: TEST ja LIVE. Arenduseks eraldi keskkonda ei ole – kogu arendus toimub lokaalselt arendajate töövahendites ning Git feature- branchide kaudu. Test- ja live-keskkonnad töötavad Kubernetesel ning on eristatud läbi konteineri- image, configmap’ide ja secrete'ite.

Alljärgnevalt on kirjeldatud, kuidas toimub versioonihaldus, konteinerite ehitamine, loomine ja käivitamine, ning kuidas on jagatud andmebaasi- ja SAP-allikakeskkonnad.

SAP HANA allikad

Vertica LIVE andmebaas

Vertica TEST andmebaas

Kubernetes klaster

Git & CI/CD

Kohalik arendus

LIVE namespace

TEST namespace

arendus ja lokaalne testimine

PodCreate

PodCreate

PodCreate

PodCreate

PodCreate

PodCreate

keskkonna seaded

keskkonna seaded

Hop GUI kohalik masin

dbt-vertica Python venv

Liquibase Docker Desktop

(valikuline) kohalik k3s/k3d + Kestra

Feature branch (JIRA task)

develop branch

main branch

CI pipeline build image :develop

CI pipeline build image :main

Container Registry registry.tehik.ee

Kestra TEST Hop pods

(image :develop)

dbt pods (image :develop)

Liquibase pods (image :develop)

Kestra LIVE

Hop pods (image :main)

dbt pods (image :main)

Liquibase pods (image :main)

ConfigMap + Secrets TEST

ConfigMap + Secrets LIVE

DEV_DW_STEEL_*_ODS

DEV_EDW_STEEL (EDW + DWH dev)

DW_STEEL_*_ODS

EDW_STEEL (EDW test)

DWH_STEEL (DWH test)

DW_STEEL_*_ODS

EDW_STEEL (EDW)

DWH_STEEL (DWH)

SAP TEST baas

SAP LIVE baas

Git–CI/CD loogika ja konteinerite ehitamine

Arenduse töövoog

Arendamiseks ei ole eraldi serverikeskkonda. Koodi arendus toimub lokaalselt:

HOP – arendus Hop GUI abil arendaja arvutis. dbt – arendus Python virtuaalkeskkonnas dbt-verticaga. Liquibase – DDL arendamine ja testimine Docker Desktopi abil. Kestra – vajadusel võimalik käivitada lokaalne k3s/k3d keskkond Kestra jooksutamiseks.

Arendaja töövoog:

1. Arendaja loob feature-branchi (nimega vastavalt JIRA taskile). 2. Arendused tehakse lokaalselt, testitakse lokaalselt. 3. Feature-branchist tehakse merge request → develop .

Test-keskkonna CI/CD

Kui merge request kinnitatakse ja kood jõuab develop harusse:

1. CI pipeline ehitab tööimage (HOP, dbt runner, Liquibase). 2. Image märgistatakse tagiga :develop . 3. Image pushitakse TEHIK container registry’sse. 4. Kestra TEST keskkond kasutab ephemeral podide loomiseks alati :develop tagiga image’e.

Test-keskkond on seega arenduse ametlik kontrollpunkt, kus testitakse:

laadimised, dbt mudelite ehitamine, DDL muudatused, Kestra töövoogude korrektne toimimine, andmevoogude terviklikkus.

Live-keskkonna CI/CD

Kui test-keskkonnas on kõik kinnitatud ning develop → main merge on tehtud:

1. CI pipeline ehitab uue tööimage main-branchi seisust. 2. Image märgistatakse tagiga :main . 3. Image pushitakse registrisse. 4. Kestra LIVE keskkond kasutab ephemeral podide loomiseks :main tagiga image’e.

Live saab seega ainult CI kaudu, mitte kunagi käsitsi.

Kubernetes ja keskkondade eraldatus TEST ja LIVE keskkonnad jooksevad eraldi Kubernetes namespace’ides. Keskkondade eraldatus saavutatakse läbi:

eraldi ConfigMapide, eraldi Secretite, eraldi image tagide ( :develop ja :main ), eraldi andmebaasiskeemide, eraldi SAP-allikate kasutuse.

Igal keskkonnal on:

oma ühendusparameetrid, oma salajased võtmed (secretid), oma schedulerid, oma Kestra vood, oma pod’ide konfigureerimine (ressursid, ajastus, connection-id’d).

TEST ja LIVE ei jaga mitte midagi – isegi mitte ajastusi.

Vertica keskkonnad ja skeemid Vertica-s on kolm loogilist tegevusruumi:

1. Arendus – toimub test-andmebaasi arendusskeemides. 2. Test – toimub test-andmebaasi testskeemides. 3. Live – eraldi prod-andmebaasis.

Arenduse skeemid Verticas

Arendus ei toimu eraldi serveris, vaid test-baasi arendusskeemides:

ODS: DEV_DW_STEEL_HERP_ODS

DEV_DW_STEEL_CRM_ODS

DEV_DW_STEEL_DERP_ODS

EDW: DEV_EDW_STEEL

DWH: DEV_EDW_STEEL (sama skeema sisaldab DWH objekti taset)

Siin saavad arendajad jooksutada test-laadimisi, teste ja dbt-mudeleid.

Test-keskkonna skeemid Verticas

Testimiseks kasutatakse sama andmebaasi eraldi skeeme:

ODS: DW_STEEL_HERP_ODS

DW_STEEL_CRM_ODS

DW_STEEL_DERP_ODS

EDW:

EDW_STEEL

DWH: EDW_STEEL (DWH osa samas skeemas)

Need skeemid töötavad koos Kubernetes TEST image’idega ja Kestra TEST ajastusega.

Live-keskkond Verticas

Live töötab eraldi Vertica andmebaasis, kus skeemide nimetused on testiga identsed:

DW_STEEL_HERP_ODS

DW_STEEL_CRM_ODS

DW_STEEL_DERP_ODS

EDW_STEEL

See tagab, et deploymentid on skeema-tasandil 1:1 ülekantavad test → live.

SAP HANA allikad test- ja live-keskkondades SAP allikate loogika:

SAP TEST: kasutatakse ODS → EDW → DWH testkeskkonda laadimiseks andmemahud on ligikaudu 3× väiksemad kui live andmed ei kasva orgaaniliselt; muutused toimuvad käsitsi või arendajate initsiatiivil

SAP LIVE: kasutatakse ainult live keskonda laadimiseks andmed arenevad loomulikult äriprotsessidest

Andmeid ei tooda keskkondade vahel üle.

Lisa 2 – Kodukord

1. Sissejuhatus

1.1. Kodukorra eesmärk on täpsustada poolte õiguseid ja kohustusi ja tööde teostamise

korraldust.

2. Nõuete haldus

2.1. Antud peatüki eesmärk on kirjeldada kust ja kuidas nõuded tulevad, kuidas nõuded

kaardistatakse, kuidas neid hallatakse, kuidas hallatakse muudatusi, sh kuidas

kinnitatakse muudatused, kuidas ärilised nõuded seotakse süsteeminõuetega ja kuidas

süsteeminõuded seotakse arenduse taskide, testilugude jms-ga.

2.2. Projekti skoopi kuuluvad tööd on kirjeldatud hanke tehnilises kirjelduses ja selle lisades.

Nende tööde teostamise jälgimiseks loob täitja projektijuht võimalikult sarnase

töömahuga piletid projekti tööhalduskeskkonnas. Pileteid võib samadel tingimustel luua

ka tellija. Projektis ei teostata töid, mida pole hanke tehnilises kirjelduses defineeritud (ja

mille kohta ei ole seega tööhalduskeskkonnas piletit).

2.3. Tööde läbivaatamisel võib tellija tuua välja erinevaid muudatusvajadusi, mis

defineeritakse projekti töörühma poolt tööhalduskeskkonna vastavas piletis nõuetena

või uute tööpiletitena.

2.4. Dokumentatsiooni loomisel tuleb lähtuda suunistest mis on kättesaadaval aadressil

https://tehik.ee/arendusjuhendid („Nõuded infosüsteemi dokumentatsioonile“).

3. Kommunikatsiooni haldus

3.1. Tellija projektijuht säilitab kogu projekti vältel toimuva kommunikatsiooni, mida on

võimalik kirjalikult taas esitada, projekti ja garantiiperioodi kehtivuse vältel.

3.2. Projekti kommunikatsiooni vormid on järgmised, kuid neile võib vastavalt vajadusele

kokkuleppeliselt lisanduda ka muid kommunikatsiooni vorme, mida pole alljärgnevas

tabelis kirjeldatud:

Kommunikatsiooni

vorm

Sagedus Vastutav

roll

Reeglid

Igapäevane

teabevahetus

Jooksvalt Tellija PJ

Täitja PJ

 Tööde läbiviimiseks lepib

töörühm kokku vestluskanali

(Teams vms), millesse kuuluvad

kõik töörühma liikmed.

Projektijuhid tagavad, et kõigil

osalistel oleks kanalisse ligipääs

 Vajadusel lepivad poolte

projektijuhid kokku antud

kanalis täiendavate

alamgruppide loomise

konkreetsete teemade

arutamiseks

 Poolte projektijuhid vastutavad,

et ebaturvalistes peetavates

vestluskanalites ei edastataks

tundlikke andmeid (n

delikaatsed isikuandmed, tellija

rakenduste turvalisust puudutav

info).

 Vestluskanalis tõstatatud

küsimusele tuleb vastata

koheselt või anda vastamise

tähtaeg.

 Mõlema poole projektijuhid

jälgivad jooksvalt vestluskanalit

ning viivituste korral korraldavad

vastamise enda poolel

 Vestluskanalis langetatud

otsused tuleb eraldi

dokumenteerida

projektidokumentatsioonis või

tööde halduse keskkonnas.

Ad hoc koosolekud Vastavalt

vajadustele

Tellija PJ

Täitja PJ

 Keerulisematele küsimuste

arutamiseks võivad tellija ja

täitja projektijuht kokku kutsuda

eraldi koosoleku.

 Koosolekule võib kutsuda ka

liikmeid väljastpoolt projekti

töörühma.

 Koosolekust antakse ette teada

vähemalt 1 tööpäev.

 Koosolekusse tuleb märkida

päevakord, eesmärk ning

toimumise koht.

 Koosolek võib toimuda nii

kohapeal kui veebi vahendusel.

 Koosoleku tulemina koostab

kokku kutsuja memo või

delegeerib selle koostamise

mõnele koosoleku osalejale.

 Kui koosoleku osalejad ei suuda

leida vastust, eskaleerib

koosoleku kokku kutsuja

otsustamise projekti töörühma

üldkoosolekule.

 Koosolekut võib tühistada

poolte kokkuleppel hiljemalt 2-

tunnise etteteatamise ajaga

Projekti

dokumentatsioon

Jooksvalt Tellija PJ

Täitja PJ

 Projekti dokumentatsioon

hoitakse tellija Confluence’i

keskkonnas vastavas ruumis.

 Tellija PJ vastutab, et kõigil

töörühma liikmetel oleks sinna

ligipääs.

 Dokumentatsiooni struktuur

lepitakse kokku projekti

töörühma koosolekul. Igale

dokumendile määratakse tellija

ja täitja jälgija.

 Projektijuhid vastutavad, et

dokumendi jälgijad teostaksid

dokumendi kokkulepitud

täiendused ja muudatused ning

et dokumentatsioon püsiks

ajakohane.

Projekti

tööülesanded

Iganädalaselt Tellija PJ

Täitja PJ

 Projekti kõiki tööülesandeid

hallatakse tellija Jira keskkonna

vastavas projektis. Selles

keskkonnas registreerimata töid

ei teostata ega arveldata.

 Tellija PJ vastutab, et kõigil

töörühma liikmetel oleks

tööhalduskeskkonda ligipääs.

 Igal teostamisele määratud

ülesandel peab olema täitja

 Ülesande täitja vastutab

ülesande täitmise staatuse

ajakohasena hoidmise eest

 Ülesanded vaadatakse läbi kord

nädalas ning märgitakse juurde

vastavad tegevused.

Lepingu täitmist

puudutav

teabevahetus

Vastavalt

vajadusele

Tellija PJ

Täitja PJ

 Lepingu täitmist puudutav

ametlik teabevahetus, mis pole

kaetud muude

kommunikatsioonivormidega (n

tööülesannete ja

projektidokumentatsiooni

haldus) toimub e-kirja teel.

 Ametlikud e-kirjad registreerib

tellija projektijuht tellija

dokumendihalduse keskkonnas

 Kui e-kirjale oodatakse vastust,

tuleb see pealkirja real või kirja

alguses üheselt määratleda.

 Vastust eeldavale e-kirjale tuleb

vastata hiljemalt järgneva

tööpäeva jooksul. Kui see ei ole

võimalik, tuleb järgneva

tööpäeva jooksul anda sisulise

vastamise tähtaeg.

 Lepingu üleandmis-vastuvõtu

akt (ÜVA) tuleb tellija poolsele

lepingu kontaktile edastada

meili teel ja digitaalselt

allkirjastatuna. Tellija korraldab

ÜVA registreerimise ja

allkirjastamise

dokumendihaldussüsteemis

ning täitjale meili teel

tagastamise.

 Arved lepingu täitmise eest

esitatakse e-arvete keskkonnas.

Erakorraline

teabevahetus

Vastavalt

vajadusele

Tellija PJ

Täitja PJ

 Poolte vaheline teabevahetus,

mis pole kaetud eelnevalt

kirjeldatuga, lepitakse kokku

tellija ja täitja PJ poolt vastavalt

olukorrale.

 Projektijuhid lepivad kokku,

millises vormis erakorraline

kommunikatsioon edastada ning

kuidas seda edasi käsitleda.

 Reeglina on erakorralise

kommunikatsiooni vormiks

ametlik e-kiri, mis

registreeritakse tellija

dokumendihalduse süsteemis.

 Kommunikatsioon

kriisiolukorras on kirjeldatud

käesoleva dokumendi punktis 5.

4. Projekti muudatuste haldus

4.1. Projekti muudatuseks nimetatakse vajadust, mida pole varasemalt kokku lepitud

projekti ressurssides, skoobis (sh nõuetes, tulemites, verstapostides, eeldustes,

piirangutes või seostes) või tööplaanis ja mille realiseerimine toob kaasa muudatusi

varasemalt kokku lepitud:

4.1.1. üle antavates tulemites ja/või

4.1.2. ajakavas, projekti eelarves, inimressurssides ja/või

4.1.3. projekti läbiviimise tööprotsessides

4.2. Muudatustaotlused registreerib ja nende menetlemise seisu jälgib tellija projektijuht

projektidokumentatsiooni keskkonnas.

4.3. Registreeritud muudatustaotlused vaatavad poolte projektijuhid koos läbi,

konsulteerides vastavalt vajadusele projekti töörühmaga. Läbivaatuse käigus

märgitakse taotlusse muudatuse mõju projekti tulemitele, ajakavale, eelarvele ning

inimressursside kasutamisele.

4.4. Enne muudatustaotluse esitamist tuleb tagada, et on olemas vajalikud eeldused

muudatuse teostamiseks.

4.5. Juhul, kui muudatus eeldab lisarahastust, hankes nimetamata ressursside kaasamist

projekti või läheb muul viisil vastuollu riigihanke dokumentatsiooni sõnastusega, peab

tellija projektijuht koostama muudatust põhjendava memo ning kooskõlastama selle

tellija dokumendihaldussüsteemis vastavalt kehtivale asjaajamiskorrale.

4.5.1. Muudatus ei tohi tekitada täitjale eelist võrreldes teiste riigihankes kandideerinud

pakkujatega.

4.6. Muudatuse realiseerimisega alustatakse alles peale vajalike kooskõlastuste saamist ning

vajadusel hankelepingu või projekti kodukorra muudatuse allkirjastamist mõlema poole

poolt.

5. Probleemide haldus

5.1. Kriisiolukorraks loetakse olukorda, kus:

5.1.1. poolte esindajad ei suuda kokkuleppele jõuda;

5.1.2. on muutunud võimatuks võtmeisikute osalemine tööde teostamisel;

5.1.3. on ilmnenud muud asjaolud, mis võivad oluliselt mõjutada tööde edukat elluviimist

ja/või satuvad olulisse ohtu kokkulepitud tähtajad ja/või funktsionaalsus.

5.2. Kriisiolukorra tekkimisel on pool kohustatud sellest teise poole esindajat viivitamatult

teavitama e-maili teel. Poole projektijuht helistab lisaks üle teise poole projektijuhi ning

kontrollib meili kättesaamist.

5.3. Kui telefonikõnele pole võimalik vastata, tuleb tagasi helistada esimesel võimalusel, aga

mitte hiljem kui järgmise tööpäeva lõpus.

5.4. Kriisi tekkel informeerib tellija projektijuht koheselt TEHIK-u andmeanalüüsi ja/või

andmeladude talituse juhte, kes rakendavad täiendavad meetmed kriisi lahendamiseks.

5.5. Kriisist väljumiseks teevad mõlemad pooled kõik endast sõltuva mõlemat poolt

rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise tegevuste edenemise

eest vastutavad poolte projektijuhid.

5.6. Kriisisituatsioonis võivad projektijuhid kokku leppida vajalike isikute kättesaadavuse ka

peale tööpäeva lõppu.

5.7. Kui eelnevate meetmete abil ei suudeta kriisist väljuda, kasutatakse täitja ja tellija

vahelises lepingus sätestatud meetmeid.

6. Kvaliteedi tagamine

6.1. Juhtimise kvaliteet tagatakse käesolevas projektis läbi süstemaatilise ja aktiivse

projektijuhtimise, kus regulaarselt jälgitakse kokkulepitud tööplaani ja tööprotsesse ning

muid hanke- ja projektidokumentatsioonis sõnastatud meetodeid, reegleid ja

põhimõtteid.

6.2. Töö teostaja tagab, et projekti üle antavate tulemite kvaliteedi tagamiseks on tulemid

(tarned) eelnevalt testitud vastu esitatud (sh funktsionaalseid ja mittefunktsionaalseid)

nõudeid ning tuvastatud vead on parandatud enne tellijale üleandmist.

7. Tulemite valideerimine ja kinnitamine

7.1. Selliste tulemite nagu aruanded ja dokumentatsioon valideerimiseks vaatab tellija

analüütik tulemid läbi, rakendades neid toodangukeskkonna andmetele ning kinnitab

tulemite vastavust enda ärivajadustele tellija tööhalduskeskkonnas. Tööd ei võeta vastu

enne, kui tellija analüütik või tema esindaja on tööhalduskeskkonnas kinnitanud loodud

tulemi sobivust.

7.2. Laadimise koodi ja infodomeenile vastava andmemudeli vastavust nõuetele kontrollib

tellija andmelao spetsialist (arendaja, arhitekt) versioonihaldus keskkonnas (GIT).

7.3. Andmeparandusalgoritmide valideerimiseks tuleb tagada, et need on tellija keskkonnas

rakendatud, tellija andmelao arendaja on kinnitanud nende sobivust ning tellija analüütik

on kinnitanud, et aruanded, mille andmekoosseisu algoritmid mõjutavad, on

vastuvõetavad.

7.4. Dokumentatsiooni vastavust kehtivatele mittefunktsionaalsetele nõuetele kontrollib

tellija projektijuht, kaasates vastavalt vajadusele täiendavaid spetsialiste.

8. Riskide haldus

8.1. Riskide haldus hõlmab:

8.1.1. riskide tuvastamist, analüüsi ja riskide prioriseerimist,

8.1.2. riskide juhtimistegevuste planeerimist,

8.1.3. riskide juhtimist,

8.1.4. riskide juhtimistulemuse kontrollimist ning otsustamist, kas risk on kontrolli all või vajab

lisategevusi.

8.2. Riskide halduse reeglid ja protsess on järgmine:

8.2.1. täitja projektijuht koos projektimeeskonnaga koostab esialgse riskiplaani

vastavalt alljärgnevale tabelile:

I

D

Valdkon

d

Riski

kirjeldu

s

Riski

realiseerumis

e tagajärg

Risk

i

mõj

u

(M)

Riski

realiseerumis

e tõenäosus

(TN)

Skoo

r (S)

Riski

juhtimise

tegevuse

d

Vastutaj

a

8.2.2. Riskiplaan sisaldab järgmist infot:

8.2.2.1. riski _ID;

8.2.2.2. riski valdkond (nt: kliendist tulenevad riskid, finantsidest tulenevad

riskid, ajahinnangutest tulenevad riskid, skoobist tulenevad riskid,

tehnilisest lahendusest tulenevad riskid jne);

8.2.2.3. riski kirjeldus;

8.2.2.4. riski tagajärg;

8.2.2.5. riski mõju;

8.2.2.6. riski realiseerumise tõenäosus (TN);

8.2.2.7. riskikoefitsient/ skoor;

8.2.2.8. riski juhtimise tegevused ja vastutajad.

8.2.3. Riskiplaan arutatakse läbi kõigi seotud osapooltega.

8.2.4. Riskiplaani muudatusi haldab täitja projektijuht, küsides regulaarselt tagasisidet

projekti meeskonnalt ja tellija projektijuhilt.

8.2.5. Riskiplaanis olevad kõrge prioriteediga riskid ja nende juhtimise tegevused,

vastutajad ja seis vaadatakse üle projekti juhtrühmas.

8.2.6. Riskiplaani hoitakse ning hallatakse tellija dokumendihalduskeskkonnas

(Confluence).

8.3. Riskide hindamine

8.3.1. Riskide hindamine hõlmab riskide tuvastamist, analüüsi ning riskikoefitsiendi/skoori

määramist.

8.3.2. Riskide hindamisel osalevad kõik täitja projektimeeskonna liikmed, projektijuhi

ülesanne on tulemused kaardistada ning tagada riskiplaani aja- ja asjakohasus.

8.3.3. Riskide hindamise reeglid on:

8.3.3.1. riski esinemise tõenäosus 3 palli süsteemis (madal - 1, keskmine – 2,

kõrge - 3);

8.3.3.2. riski mõju 3 palli süsteemis (madal - 1, keskmine – 2, kõrge - 3);

8.3.3.3. skoor on riski esinemise tõenäosuse ja mõju korrutis (S = TN x M);

8.3.3.4. prioriteetsed riskid - koefitsiendiga 4-9 - kuuluvad alati ülevaatamisele

projekti juhtrühmas;

8.3.3.5. partneriga seotud riskide hindamisel kaasatakse partneri esindaja/

projektijuht, kes vajadusel kaasab hindamisprotsessi omapoolsed

spetsialistid.

8.4. Riskide kontroll

8.4.1. Riskide kontroll hõlmab riskide juhtimise tulemuste kontrollimist ning otsustamist, kas

on lisandunud uusi riske, kas on muutunud mõne riski skoor, millised on abinõud riskide

edasiseks juhtimiseks.

8.4.2. Konkreetsete tegevuste täitmise eest vastutajad ning tähtajad kannab täitja

projektijuht üldisesse tööplaani. Nimetatud tegevuste täitmist kontrollib ja esitab

ülevaate täitja projektijuht projekti edenemise seisu raportis.

9. Tööprotsessid

9.1. Antud peatüki eesmärk on kirjeldada olulisemad tööprotsessid selleks, et meeskonnal

oleks ühene arusaam, kes, mida, millal ja kuidas teeb. Nt protsess, kuidas toimub mingite

nõuete ja analüüsitulemite ülevaatus ja kinnitamine projekti erinevate osapoolte vahel.

9.2. Projekti alguses toimub avakoosolek (vajadusel mitu) ning luuakse kõigile osapooltele

vajalikud ligipääsud tööde teostamiseks.

9.3. Täitja teostab arendustööd vastavalt hanke tehnilisele kirjeldusele ja selle lisadele.

9.4. Arendustööd teostatakse täitja poolt tellija poolses keskkonnas, millele tellija

organiseerib täitja jaoks vajalikud ligipääsud.

9.5. Tööde tulemid peavad olema täitja poolt testitud ning vastama tehnilises kirjelduses ja

selle lisades seatud ootustele vastavalt hankelepingus ja tehnilises kirjelduses

ettenähtud ajaraamile ning tähtaegadeks.

9.6. Tööde registreerimiseks teavitab tellija täitjat töö vajadusest, esitades töö ettepaneku

tööde / vigade halduskeskkonnas.

9.7. Täitja kirjeldab eelanalüüsi käigus vastavalt tellija poolt esitatud lähteülesandele

tööle tehnilise lahenduskäigu ning annab tööle mahuhinnangu tundides.

9.7.1. Kui tööd ei ole võimalik enne teostamist hinnata, siis arendaja teavitab sellest tellijat.

9.7.2. Tellija kinnitusel võtab täitja sõltuvalt töö skoobist mõistliku mahu (4 kuni 8h) tööga

tutvumiseks ja annab selle kohta teavituse töö piletisse enne tööga alustamist.

9.7.3. Täitja annab tööga tutvumise järgselt tööle seejärel lõpliku hinnangu alles peale

mainitud aja jooksul tööga tutvumist. Kui töö nende tundide jooksul laheneb, siis

täiendavat hinnangut ei teki.

9.8. Tellija kinnitab töö teostamise ja suunab selle töödekuhja pakkujale teostamiseks.

9.8.1. Tellijal on õigus pakutud mahuhinnang tagasi lükata või töö teostamine peatada ning

arendustööd mitte tellida.

9.9. Täitja teostab tööde osas aruandlust.

9.9.1.Täitja peab tööde osas arvestust rollide kaupa ja esitab tööde kohta aruande tööde

üleandmise ja vastuvõtmise aktis sisalduva tabeli kujul.

9.9.2. Täitja esitab tellijale aruande iga kuu kohta, mis sisaldab täitja poolt veaparandus

ja/või tellimuste alusel tehtud tööde (sh garantiiliste tööde) nimekirja (sh. tarneid ja

vastuvõetud töid) ning mahtu (töötunnid).

9.9.3. Täitja esitab aruanded tellijale vähemalt 1 kord kuus.

9.10. Täitja peab salvestama tööde aruandlust (logima töö teostamiseks kulunud aega)

tööde/vigade halduskeskkonnas (Jira) kasutades selleks tellija poolt aktsepteeritud aja

logimise lahendust (TEMPO).

9.10.1. Täitja peab tööde teostamiseks kulunud aega salvestama vastava töö pileti külge

iga päev kui tööd on tehtud.

9.10.1.1. Ei ole aktsepteeritav, et täitja esitab ajaaruanded töö pileti tasemel

suuremas mahus kui 1 päev (8 tundi) viivitusega.

9.10.2. Tööde aruandluse salvestamine tööde/vigade halduskeskkonda on kohustuslik ja on

tööde akteerimise aluseks.

9.11. Täitja annab aruande alusel tööd üle aktiga.

9.11.1. Akteerimisele kuuluvad ainult tööd, mis on hinnatud või muul juhul tellija poolt töösse

kinnitatud ja peale täitja poolset tööde teostamist tellija poolt tööde / vigade

halduskeskkonnas vastu võetud ja/või jõudnud muu resolutsioonini (nt. katkestatud,

tühistatud, ...), kus tellija kinnitab teostatud tööde akteerimise.

9.11.2. Tellijal on õigus töösse eelnevalt kinnitamata täitja poolt raporteeritud töötunde

mitte akteerida.

9.12. Täitja suunab tööga seotud pileti tellijale kui töö on valmis vastuvõtutestimiseks (test)

keskkonnas.

9.12.1. Piletisse tuleb märkida seos nõuetega, vastavalt hanke tehnilisele kirjeldusele ja selle

lisadele, mida see pilet mõjutab.

9.12.2. Piletisse tuleb lühidalt kirjeldada teostatud töö tulem ning võimalusel viidata tehtud

tööle tellija keskkonnas ja/või koodi asukohale koodihalduskeskkonnas.

9.12.3. Piletisse tuleb märkida viide dokumentatsioonile, mida tööde käigus loodi, muudeti

või täiendati.

9.12.4. Kulupõhise arvelduse puhul peab piletis olema tööde teostamiseks kulunud aeg

(TEMPO).

9.13. Suunamise eest järgmisele täitjale vastutab vaikimisi isik, kelle nimel pilet on.

9.13.1. Uute piletite määramise eest täitjale vastutatavad tellija ja täitja projektijuhid.

9.14. Tööde tarnimine täitja keskkondadest tellija keskkondadesse toimub peale täitjaga

kooskõlastamist ning tarnete puhul lähtutakse tellija muudatuste halduse protsessist.

9.15. Tellija testib tulemeid esialgu võimalusel test keskkonnas ja peale tarnet ka toodangu

(live) keskkonnas.

9.15.1. Juhul kui töös esineb vigu, annab tellija omalt poolt tagasisidet täitjale, et täitja saaks

teha vajalikud parandused.

9.16. Tellija kinnitab tulemid, kui need vastavad tehnilises kirjelduses ja selle lisades seatud

ootustele tulemi suhtes toodangu keskkonnas (live) – Definition of Done (DoD).

10. SCRUM protsessid

10.1. Antud peatükki kohaldatakse juhul, kui projektis on kasutusel SCRUM

arendusmetoodika.

10.2. Tellija on tooteomaniku (Product Owner; PO) rollis.

10.3. Täitja on Scrum Master (SM) rollis.

10.4. SCRUM sündmused

10.4.1. Sprint on Scrum-i konteinersündmus.

10.4.2. Sprint sisaldab kõiki vajalikke töid sh:

10.4.2.1. Analüüs

10.4.2.2. Disain

10.4.2.3. Arhitektuur

10.4.2.4. Arendus

10.4.2.5. Testimine

10.4.2.6. Jne.

10.4.3. Sprint kestab 1-4 nädalat (maksimaalselt 1 kuu).

10.4.3.1. Enamasti on kokkuleppeliselt projektis sprindi kestvuseks 1-2 nädalat.

10.4.4. Sprint võimaldab prognoosimist ja riski piirangut – iga sprindi lõpus on mõõdetav

tulemus.

10.4.5. Sprindi võtmesisendid:

10.4.5.1. Toote backlog

10.4.5.2. Tiimi võimekus (velocity; capacity)

10.4.5.3. Valmimiskriteeriumid (DoD – Definition of Done)

10.4.5.4. Viimane töötav tarkvara versioon (increment) ja tagasiside

retrospektiivist.

10.4.6. Sprindi eesmärk on võtmeväljundina luua töötav ja potentsiaalselt lansseeritav

(tootestatav) tarkvara versioon (increment).

10.4.7. Sprindi sündmused:

10.4.7.1. Sprint planning – Sprindi alustamine õige fookusega.

10.4.7.1.1. Eesmärk:

10.4.7.1.1.1. Määrata, millised tööülesanded lähevad toote backlogist

sprindi backlogi.

10.4.7.1.1.2. Koostada plaan, kuidas sprindi jooksul seatud eesmärk

saavutada.

10.4.7.1.2. Kestvus ja regulaarsus:

10.4.7.1.2.1. Kuni 2 h iga nädala kohta (maksimaalselt 8 h 4-nädalase

sprindi kohta).

10.4.7.1.3. Väljund:

10.4.7.1.3.1. Sprint backlog – konkreetne tööplaan kogu sprindi jaoks.

10.4.7.2. Daily Scrum – Igapäevane lühikoosolek sprindi sujuvaks edenemiseks.

10.4.7.2.1. Eesmärk:

10.4.7.2.1.1. Ülevaade viimase 24h progressist sprindi eesmärgi

suhtes.

10.4.7.2.1.2. Vajadusel sprindi backlogi uuendamine.

10.4.7.2.2. Kestvus ja regulaarsus:

10.4.7.2.2.1. Kuni 15 minutit iga päev samal ajal.

10.4.7.2.3. Väljund:

10.4.7.2.3.1. Järgmise 24h plaan.

10.4.7.3. Sprint Review – Iteratiivne tagasiside sessioon.

10.4.7.3.1. Eesmärk:

10.4.7.3.1.1. Vaadata üle sprindi jooksul valminud versioon

(increment).

10.4.7.3.1.2. Vajadusel uuendata toote backlogi lähtuvalt

tagasisidest.

10.4.7.3.2. Kestvus ja regulaarsus:

10.4.7.3.2.1. Iga sprindi lõpus 1 kord kuni 1 h iga nädala kohta

(maksimaalselt 4 h 4-nädalase sprindi kohta).

10.4.7.3.3. Väljund:

10.4.7.3.3.1. Uuendatud toote backlog.

10.4.7.4. Sprint Retrospective – tiimi eneseanalüüs ja parendamine.

10.4.7.4.1. Eesmärk:

10.4.7.4.1.1. Selgitada välja parendused, mida saab rakendada

järgmise sprindi jooksul.

10.4.7.4.2. Kestvus ja regulaarsus:

10.4.7.4.2.1. Kohe pärast Sprint Review-d 1 kord kuni 1 h ia nädala

kohta (maksimaalselt 4 h 4-nädalase sprindi kohta).

10.4.7.4.3. 1-2 planeeritud parendust järgmisesse sprinti.

11. Tööde piirangud

11.1. Tööde teostamisel peab arvestama, et TEHIKu pärandandmelaod laadivad

infosüsteemide PostgreSQL ja Oracle baasidest Pentaho abil SAP IQ andmeladudesse.

Andmeanalüüsi keskkonnana on kasutusel WebFocus, sh veebipõhine töökeskkond

WebFOCUS InfoAssist.

11.2. Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud

tellija IT profiilis. IT profiili ning teiste kohalduvate dokumentide viited

(mittefunktsionaalsed nõuded, nõuded andmeladude arendusele, automaattestimisele)

ning nende materjalide kasutamine ja kohaldamine raamlepingu jooksul on täpsemalt

kirjeldatud raamlepingus.

11.3. Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid

tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete

presenteerimiseks).

11.4. Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued

komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei

ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides

järgnevate tegevuste eest:

11.4.1. mikroteenuste loomine vastavalt tellija poolt esitatud arhitektuuriplaanile;

11.4.2. täies mahus CI/CD töövoogude koostamine;

11.4.3. rakenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning

testkeskkonda koos tellija poolse süsteemiadministraatoriga;

11.4.4. regulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt;

11.4.5. automaatsete testide koostamine vastavalt TEHIKu automaattestide koostamise

juhendile;

11.4.6. peakasutaja(te) koolitamine;

11.4.7. dokumentatsiooni koostamine;

11.4.8. mittefunktsionaalse monitooringu loomine rakendustele;

11.4.9. funktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele tellijaga.

11.5. Tarkvara arenduse käigus tuleb lähtuda suunistest, mis on kättesaadaval aadressil

https://tehik.ee/arendusjuhendid.

11.6. Tarkvara arenduse puhul tuleb eelistada konteiner lahendusi. Esimene eelistus Apache

Hop või custom konteiner (tuleb kooskõlastada arhitektiga).

11.7. Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke.

Juhul, kui on vajadus kasutada mõnda avalikku või mingit muud teeki, siis see tuleb see

enne kooskõlastada tellija arhitektiga.

11.8. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga.

11.9. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega

keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul, kui

täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda,

luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud.

11.9.1. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate

andmeladude toodangueelsetele keskkondadele.

11.9.2. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone,

andmeparandusfunktsioone ning aruandluskeskkondi.

11.9.3. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel

GitLab

11.9.4. Sõltuvuste repositoorium on vaikimisi tellija Artifactory.

11.9.5. Kubernetese halduseks on kasutusel Rancher.

11.9.6. Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda

https://wiki.sm.ee.

11.9.7. Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee.

11.9.8. Aja logimiseks on kasutusel Tempo.

11.9.9. Aktsepteeritud suhtluskanaliteks on tellija Rocket.Chat, Microsoft Teams, tellija

Jira/Confluence ja e-mail.

11.9.10. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult

VPN tunneli kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks

on vajalik Eesti ID kaart või Digi-ID.

ISIKUANDMETE TÖÖTLEMISE TINGIMUSED

... (edaspidi volitaja), registrikood //, asukohaga //, keda esindab direktor //

ja

..... (edaspidi volitatud töötleja), registrikood //, asukohaga //, keda esindab juhatuse liige/volikirja

alusel //.

on sõlminud käesoleva isikuandmete töötlemise lepingu hankelepingu nr // lisana nr // (edaspidi

leping):

1. Ese ja eesmärk

1.1. Lepingu esemeks on volitaja ja volitatud töötleja (edaspidi koos nimetatud kui pooled)

vaheliste tingimuste sätestamine seoses /...hankelepingu nimetus.../ tööde käigus

käsitletavate andmete töötlemisega.

1.2. Volitatud töötleja töötleb lepingus kirjeldatud isikuandmeid hankelepingu nr //

täitmiseks, millele on volitatud töötlejal õigus saada ligipääs hankelepingus

määratletud tööde teostamiseks vastavalt lepingus sätestatud piirangutele.

1.3. Lepingu täitmiseks on volitatud töötleja isikuandmete töötlemisega seotud tegevused

lepingu alusel piiratud hankelepingu täitmiseks vajalike tegevustega.

1.4. //.

2. Isikuandmed

2.1. Volitatud töötlejale võivad hankelepingu täitmise käigus teatavaks saada volitaja poolt

hallatavas infosüsteemis või // andmekogus töödeldavad isikuandmed järgmises

koosseisus:

2.1.1. /... Infosüsteemi nimetus .../ andmed vastavalt // pp.kk.aaaa määruse nr // /...

määruse nimetus .../ peatükile nr // /... peatüki nimetus .../.

2.1.2. //

2.1.3. VÕI

2.1.4. //

2.1.5. isikuandmed, nt inimese nimi, sünniaeg, isikukood, isikut tõendava dokumendi

andmed;

2.1.6. kontaktandmed, nt aadress, telefoninumber ja e-posti aadress;

2.1.7. eriliigilised isikuandmed, nt andmed isiku või tema pereliikme terviseseisundi,

majandusliku seisundi või perekonna kohta;

2.1.8. ameti- ja kutsesaladust puudutav teave.

2.1.9. //

3. Volitatud töötleja kohustused

3.1. Volitatud töötleja on kohustatud:

3.1.1. tagama lepingueelsete läbirääkimiste ja lepingu täitmise käigus volitajalt ükskõik mis

vormis saadud isikuandmete konfidentsiaalsuse ja mitte edastama ega võimaldama

sellele teabele juurdepääsu kolmandale isikule ilma volitaja sellekohase selgesõnalise

kirjaliku nõusolekuta;

3.1.2. tagama, et lepingu täitmise raames töödeldavaid isikuandmeid ei edastata väljapoole

Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide

territooriumi ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta;

3.1.3. kasutama ja töötlema isikuandmeid üksnes hankelepingu täitmiseks ja volitaja

dokumenteeritud juhiste alusel, välja arvatud juhul, kui volitatud töötleja on

kohustatud teavet töötlema volitatud töötleja suhtes kohalduva õiguse alusel. Viimati

nimetatud juhul teavitab volitatud töötleja volitajat vastava kohustuse olemasolust

enne teabe töötlemist;

3.1.4. võimaldama juurdepääsu isikuandmetele ainult nendele isikutele, kellel on selleks oma

tööülesannete täitmiseks vajadus ning tagab, et need isikud on teadlikud ning järgivad

isikuandmete töötlemis alaseid nõudeid ja õigusakte, nad on saanud asjakohase

koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või

neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus;

3.1.5. teavitama volitajat toimunud või põhjendatult kahtlustatavast lepingu punktis 3.1.4.

sätestatud konfidentsiaalsuskohustuse rikkumisest viivitamatult;

3.1.6. täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust

puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi

õigusakte ja muid eeskirju;

3.1.7. rakendama alltoodud organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid

isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise

ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse

takistamise eest, volitamata töötlemise, sh avalikustamise eest:

3.1.7.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele

seadmetele;

3.1.7.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist

andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist;

3.1.7.3. ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning

tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja

milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja

millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi;

3.1.7.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale

töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks;

3.1.7.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja

millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise;

3.1.7.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate

transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist,

muutmist või kustutamist;

3.1.7.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all

olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed:

3.1.7.7.1. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi;

3.1.7.7.2. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed.

3.1.8. teavitama kirjalikult volitajat turvameetmete rikkumisest, mis põhjustab, on

põhjustanud või võib põhjustada töödeldavate isikuandmete juhusliku või

ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile

juurdepääsu viivitamata, kuid mitte hiljem kui kakskümmend neli tundi pärast sellest

teada saamist. Juhul, kui rikkumisest teadasaamine langeb nädalavahetusele või

riiklikule pühale, kohustub volitatud töötleja volitajat kirjalikult teavitama

viivitamatult, kuid mitte hiljem kui nelikümmend kaheksa tundi pärast rikkumisest

teada saamist. Kirjeldatud teates tuleb vähemalt:

3.1.8.1. kirjeldada isikuandmetega seotud rikkumise laadi, sealhulgas puudutatud

andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu;

3.1.8.2. teatada andmekaitsespetsialisti või mõne teise täiendavat teavet andva

kontaktisiku nimi ja kontaktandmed;

3.1.8.3. soovitada meetmeid isikuandmetega seotud rikkumise võimalike negatiivsete

mõjude leevendamiseks;

3.1.8.4. kirjeldada isikuandmetega seotud rikkumise võimalikke tagajärgi;

3.1.8.5. kirjeldada volitatud töötleja poolt pakutud või võetud meetmeid

isikuandmetega seotud rikkumisega tegelemiseks ja

3.1.8.6. esitada muud teavet, mis on mõistlikult nõutav, et volitaja saaks täita

kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud

teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav

andmesubjekti tuvastamiseks.

3.1.9. lõpetama eelnevalt kirjeldatud rikkumised või tegema kõik endast oleneva nende

lõpetamiseks ja kohaldama meetmeid isikuandmetega seotud rikkumise

lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju

kõrvaldamiseks ja leevendamiseks;

3.1.10. kustutama, niivõrd kui see on võimalik, lepingu lõppemisel kõik tööde teostamise

käigus teatavaks saanud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a

juhul, kui õigusaktidest tuleneb teisiti;

3.1.11. tegema volitajale kättesaadavaks kogu teabe, mida volitaja peab vajalikuks lepingus

sätestatud kohustuste täitmise tõendamiseks;

3.1.12. võimaldama volitajal või volitaja poolt määratud audiitoril teha seoses isikuandmete

töötlemisega auditeid ja kontrolle ning panustama nendesse.

4. Lõppsätted

4.1. Volitatud töötleja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega

kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut.

4.2. Isikuandmete konfidentsiaalsena hoidmise kohustus jääb kehtima ka pärast käesoleva

lepingu lõppemist tähtajatult.

4.3. Isikuandmete konfidentsiaalsena hoidmise kohustus ei laiene teabe avaldamisele

volitatud töötleja audiitorile ja advokaadile.

4.4. Leping on kehtiv poolte poolt allkirjastamisest kuni hankelepingu järgsete kohustuste

täitmiseni, v.a konfidentsiaalsuskohtustus, mis kehtib tähtajatult.

5. Poole allkirjad

Volitaja: Volitatud töötleja:

/Allkirjastatud digitaalselt/ /Allkirjastatud digitaalselt/

Tööde üleandmise-vastuvõtmise akt

1. Sisu

Lähtudes Tervise ja Heaolu Infosüsteemide Keskuse, keda esindab /lepingus märgitud kontaktisik/

(edaspidi tellija) ja /ettevõtja nimi/, keda esindab /lepingus märgitud kontaktisik/ (edaspidi täitja)

vahel päev.kuu.aasta sõlmitud hankelepingu nr ___ annab täitja üle ja võtab tellija vastu teostatud

tööd.

1.1. Käesoleva aktiga annab täitja tellijale üle tööd, mis täitja on teostanud vastavalt

hankelepingule ja tellija võtab käesolevas aktis nimetatud tööd vastu.

1.2. Tellija kinnitab, et tema või tema esindajad on käesolevas aktis nimetatud tööd üle vaadanud

ning see vastab hankelepingule.

1.3. Käesolev akt on täitjale tasu maksmise aluseks. Poolte vaheline arveldamine toimub

hankelepingu alusel vastavalt käesolevas aktis sisalduvatele andmetele.

1.4. Käesoleva akti pooled kinnitavad, et aktis sisalduvad andmed on nende parima teadmise

kohaselt õiged.

2. Akteeritavad tööd

Nr Tööde loetelu

(ID) töö nimetus

Roll / Nimi Maht

(h)

Tunnihind

(€/h) KM-ta

Maksumus

kokku

(€) KM-ta

1 Roll 1 ___ €

Roll 2

2 (...)

(...)

3

4

...

___ €

3. Tööde üleandmise tähtaeg

3.1. Tööd on üle antud päev.kuu.aasta /etappide puhul ka etapid/.

3.2. Tööd teostati tähtaegselt.

4. Puudustega tööde nimekiri

4.1. Puuduseid töös ei esine./Esinevad järgmised puudused töös:

4.1.1. ____;

4.1.2. ____;

4.2. Puuduste põhjendus.

4.3. Puuduste kõrvaldamise tähtaeg on päev.kuu.aasta.

5. Poolte allkirjad

Tellija: Täitja:

Lepinguline kontaktisik lepinguline kontaktisik

/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/