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 Eelistatud Aktsepteeritav Mitte valida
Kommentaarid
(Component) (Preferred) (Acceptable) (Do not select)
Kliendi kiht (Client Layer)
Lauaarvuti ja sülearvuti
• Linux
OS / keskkond (Desktop & • Windows
• macOS
laptop client OS /
environment)
Lauaarvuti ja sülearvuti • Safari (väline
• Chromium based • Edge Legacy
kliendi kasutajaliides klient/external
• Firefox • Internet Explorer
(Desktop & laptop client client)
user interface)
• Android perekond
Mobiilse kliendi OS /
(Android family) • Windows Phone
keskkond (Mobile client
• iOS
OS / environment)
• Multi platform
• Multi platform
frameworks
• Chromium based frameworks
Mobiilse kliendi o Flutter
• Firefox o .Net based
kasutajaliides (Mobile o Kotlin
• Safari o Nativescript
client user interface) Multiplatform
o Ionic
• Native app
Esitluskiht (Presentation Layer)
Sisuhaldussüsteem • Strapi[1] • Joomla! [1] Tuleb TEHIKu arhitektiga
• Drupal
(Content management • WikiJS[1] • WordPress kooskõlastada (Must be
system) coordinated with TEHIK architect)
• Java
• JavaScript o JSP
• JavaScript
Esitluskihi raamistik o Next.JS[1] o JSF [1] Tuleb TEHIKu arhitektiga
o Angular
(Presentation framework o Single-SPA • iFrame kooskõlastada (Must be
o React
(View)) o Web-pack • Microsoft .Net coordinated with TEHIK architect)
• Python
• Apache HTTP
• Nginx • Microsoft IIS
Veebiserver (Web server) server
IT-Profiil (versioon: 3)
• Selenium • Cypress[1] [1] Tuleb TEHIKu arhitektiga
Funktsionaalne testimine
• Selenide • Playwright[1] kooskõlastada (Must be
(Functional testing)
coordinated with TEHIK architect)
Rakenduskiht (Application Layer)
• Java
o Micronaut
• C#
[1] Kogu Springi perekond (All
o .Net
• Java Spring family)
• Java o .Net
Rakenduse raamistik o Spring[1]
o Quarkus[2] Framework
(Application framework) o Spring boot [2] Tuleb TEHIKu arhitektiga
o ASP.NET
o Entity kooskõlastada (Must be
coordinated with TEHIK architect)
Framework
Core
Protsessimootor • Zeebe
(Workflow Engine)
• Java • Java
[1] Tuleb TEHIKu arhitektiga
Andmeloogika o JPA o Hibernate[1]
kooskõlastada (Must be
(Persistence framework) o JDBCTemplate o jOOQ
coordinated with TEHIK architect)
Otsingumootori indeks • Elasticsearch
(Search Engine Index)
[1] RabbitMQ
• GraphQL[2]
Integratsioon (External • AMQP [1]
• Oracle Advanced
• gRPC[2]
integration (integration to • REST Queuing [2] Tuleb TEHIKu arhitektiga
• SOAP
other systems)) kooskõlastada (Must be
coordinated with TEHIK architect)
[1] TEHIKu toode (TEHIK's
product)
• Apache Hop • Meltano[2]
Andmete laadimine (Data
• OData consumer [1] • Pentaho[2]
Loading - ETL) [2] Tuleb TEHIKu arhitektiga
kooskõlastada (Must be
coordinated with TEHIK architect)
• Webmethods
Integration Server
• .NET
o MS IIS
• Java
o Apache
• Java JServ
o Tomcat o Sun Java
o Embedded System
• Java
Aplikatsiooniserver ▪ Jetty Application
o WildFly [1] [1] VM põhine (VM based)
(Application server) ▪ Tomcat Server
▪ WildFly o SAP
o GraalVM o IBM
WebSphere
o Oracle iAS
o Oracle
iPlanet
Web Server
o WebLogic
• Insomnia
Funktsionaalne testimine • Postman
• SoapUI
(Functional testing)
• Jmeter
Koormustestimine (Load • Testkube
• Gatling
testing)
Andmekiht (Persistence Layer / Database layer)
Andmebaasi migratsioon • Liquibase • Flyway
(Database migration)
• MS SQL Server
Relatsiooniline [1] Tuleb TEHIKu arhitektiga
• PostgreSQL • MariaDB[1] • Oracle DB
andmebaas (Relational kooskõlastada (Must be
• Sybase
DBMS) coordinated with TEHIK architect)
IT-Profiil (versioon: 3)
[1] Tuleb TEHIKu arhitektiga
• MongoDB [1]
kooskõlastada (Must be
• KeyDB • Redis
Mitte ainult SQL (NoSQL) • Valkey[2] coordinated with TEHIK architect)
[2] https://valkey.io/
Andmeladu (Data • Vertica • Sybase IQ
Warehouse)
Andmete replikatsioon • Spilo
(Data Replication)
• S3 protokollil • Failid
Failide hoiustamine • MinIO põhinevad andmebaasis
(Object Storage) objektihoidlad (BLOB)
Infrastruktuuri kiht (Infrastructure Layer)
• MS Active Directory
Directory services
[1] TEHIK SSO on
Autentimine ja Ühekordne asutuseväliste kasutajate vaates
• GovSSO • TEHIK SSO [1]
sisselogimine (Authentication liikumas toe lõppemise suunas.
and Single Sign On) (TEHIK SSO is moving
towards end of life)
[1] https://www.ria.ee/riigi-
infosusteem/kesksed-
platvormid-avalike-e-teenuste-
pakkumiseks/paasuke
• TEHIK SSO + rollide api [2] On mõeldud siseste kasutajate
• Pääsuke [1]
Kasutajaõiguste haldus teenuse pool[3] rollide jaoks (Is ment for inside
• TEHIK SSO AD realm[2]
(Authorization) • MS AD (siseteenused) 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)
[1] Tootel on saabumas eluea
lõpp (Product is moving towards
Identiteedi haldus • MIM[1] end of life):
(Identity management) https://learn.microsoft.com/en-
us/lifecycle/products/microsoft-
identity-manager-2016
• Elastic Agent/Elastic • GreyLog
Logihaldus (Log Beats/Logstash • Windows Event
management) • rsyslog Collector
Süsteemi haldamine ja • Prometheus
järelevalve (System • Grafana • Zabbix • Nagios
management and • Elastic APM
monitoring)
Koormusjaotur (Traffic • Nginx • HAProxy
management)
• Squid
• Nginx
Puhverdamine (Caching) • Varnish
• Application specific
decision ie Quartz or
Tööde ajastamine (Job cron, windows
scheduling) scheduler
• k8s CronJob
• Linux (Tootja poolt
viimane pikaajalise • Linux
toega või stabiilne o Debian
Serveri • Windows
versioon) o CentOS
operatsioonisüsteem o MS (64 bit)
o Oracle Linux • IBM AIX
(Server OS)
o RedHat • Other UNIXs
o Ubuntu
IT-Profiil (versioon: 3)
• OCI compliant[1]
Konteinerid (Containers) [1] https://opencontainers.org
Konteinerite
• Kubernetes • Docker Swarm
orkestreerimine (Contaier
orchestration)
• Hyper-V
• QEMU/KVM
Virtualiseerimine • VmWare
• OracleVM
(Virtualization)
• Xen
Serveri riistvara (Server • x86_64 • RISC
hardware)
• VmWare
o Veritas
• Symantec Backup
Netbackup
Varundamine (Backup) Exec
• Kubernetes
o S3
• SAN • SAN
Kettakasti riistvara • iSCSI
o FC >= 32 Gb/s o FC >= 16 Gb/s
(Storage hardware)
Riistvaraline
krüptomoodul (HSM - • Thales • Utimaco
Hardware security
module)
• DPI (Deep packet
inspection) Layer 7
Tulemüür (Firewall) Pahavara tõrje (Anti-
malware)
Muud aspektid (Other Aspects)
• Go[1] [1] Tuleb TEHIKu arhitektiga
• NET
• JavaScript kooskõlastada (Must be
• C/C++/C#
• Java • Kotlin[1] coordinated with TEHIK architect)
Programmeerimiskeeled • Webmethods flow
• TypeScript • Python[1]
(Programming languages) • iWay Functional
• PHP[1] [2] Krüptograafiliste tegevuste
Language
• Rust[1][2] teostamiseks (To perform
cryptographic activities)
Java virtuaalmasina
implementatsioon (Java • OpenJDK • Oracle JDK
vitual machine
implemetation)
• GitLab
o Koodivaramu[1]
• SVN [1] Tuleb TEHIKu arhitektiga
Versioonihaldus (Version o TEHIK • GitHub[1]
• Atlassian Bitbucket kooskõlastada (Must be
control system) haldusalas
coordinated with TEHIK architect)
olev
• DockerHub[1]
• JFrog artifactory [1] Tuleb TEHIKu arhitektiga
Artefaktide repositoorium • GitHub Packages[1]
• Gitlab registry kooskõlastada (Must be
(Artifacts repository) • npmjs.com[1]
coordinated with TEHIK architect)
• Jenkins [1] Tuleb TEHIKu arhitektiga
Pidev integratsioon • Gitlab CI • Github Actions[1]
• Bamboo kooskõlastada (Must be
(Continuous integration)
coordinated with TEHIK architect)
• Ansible
Paigalduse automaatika • GitLab CD (dev/test) • GitHub Actions[1] • Jenkins [1] Tuleb TEHIKu arhitektiga
(Continious Deployment / • Helm (live) • Argo CD[1] • Bamboo kooskõlastada (Must be
Delivery) • Terraform coordinated with TEHIK architect)
Lähtekoodi analüüs (Code • SonarQube
analysis)
Tarkvara materjalide
• CycloneDX SBOM
loend (SBOM - software
bill of materials)
Tarkvara materjalide • Dependency-Track[1]
[1] https://dependencytrack.org
loendi analüsaator
IT-Profiil (versioon: 3)
(software bill of materials
analysis platform)
• Webfocus
• Qlik Sense
[1] Tuleb TEHIKu arhitektiga
• Tableau • Apache Superset[1] • Oracle BI Publisher
Analüütika (Analytics) kooskõlastada (Must be
• SAP® Business
coordinated with TEHIK architect)
Objects
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
ANDMEALLIKAD
SAP HANA - CRT
SAP HANA - ERT
SAP HANA - DRT Extract
Andmehaldus ja jälgimine
CI / CD
Andmekataloog ja lineage
dbt docs serve
(dbt docs)
Platform / Käivitused
Git Repos (dbt, Hop, CI Pipelines\n(unit, dbt
Liquibase) build, image build) Logid
Extract
Extract
Kubernetes HOP loader
pod'id
PodCreate ajastatud
Monitooring & teavitused
Kestra Pod PodCreate ajastatud Load
PodCreate ajastatud
Alertid
pull image
push image Container Registry VERTICA STEEL andmeait
ODS
Logid
pull image
Kubernetes Liquibase
secrets runner pod'id
Update
secrets VERTICA STEEL ärimudel
Logid
Secrets Vertica DW_STEEL_*_ODS
skeemad
Tarbijad
Kubernetes DBT runner
secrets
pod'id Analüütikud
model build Vertica DW_EDW skeema
Vertica DW_DWH skeema
connection and pod
konfiguratsioon model build BI tööriistad (Power BI)
ConfigMaps connection and pod
konfiguratsioon
profiles.yml/env
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
SAP HANA: SAP_CRT SAP HANA: SAP_DRT SAP HANA: SAP_ERT K8s nimeruum: tis-steel Kestra_Flow Liquibase_Pod Hop_Loader_Pod Vertica_DW_STEEL_(CRM|DERP|HERP)_ODS dbt_Runner_Pod Vertica_EDW_STEEL Vertica_DWH_STEEL
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
SAP HANA: SAP_CRT SAP HANA: SAP_DRT SAP HANA: SAP_ERT K8s nimeruum: tis-steel Kestra_Flow Liquibase_Pod Hop_Loader_Pod Vertica_DW_STEEL_(CRM|DERP|HERP)_ODS dbt_Runner_Pod Vertica_EDW_STEEL Vertica_DWH_STEEL
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: ODS (allika koopiad)
ODS skeemid
Skeema:
DW_STEEL_CRM_ODS
Allikatabelite koopiad STG_* abitabelid Kiht: EDW (ärimudel
HANA -> Vertica tüübitõlge ODS tabelid (allika Verticas)
Tehnilised veerud nimedega)
load - laadimise
monitooring
Kiht: DWH (aruandlus)
Skeema: Alamkiht: FINAL
Alamkiht: SNAPSHOT Alamkiht: BASE Alamkiht: CORE
DW_STEEL_DERP_ODS *_final tabelid
dbt snapshot snapshot_BASE vaated nimetused sarnased SAP Skeema: DWH_STEEL
STG_* abitabelid materjaliseeritud
andmemuudatuste ajaloo vajalike veergude valik BW mudeliga aruandluse vaated
ODS tabelid (allika tabelitena
hoidmine vajaliku ajaloolise seisu migreeritud BW loogika 1:1 peegeldused FINAL kihi
nimedega) ainult DWH-sse
materjaliseeritud valik allikaandmete ühendamine objektidest
load - laadimise eksponeeritavad objektid
tabelitena vaikimisi vaated vaikimisi vaated
monitooring eelistatult inkrementaalsed
Skeema:
DW_STEEL_HERP_ODS
STG_* abitabelid
ODS tabelid (allika
nimedega)
load - laadimise
monitooring
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 TEST andmebaas
SAP TEST baas
DEV_DW_STEEL_*_ODS
SAP LIVE baas
DEV_EDW_STEEL
(EDW + DWH dev)
Kubernetes klaster
TEST namespace
PodCreate
DW_STEEL_*_ODS
Liquibase pods
(image :develop)
PodCreate
EDW_STEEL
(EDW test)
ConfigMap + Secrets
keskkonna seaded Kestra TEST
TEST
Hop pods
(image :develop)
PodCreate
DWH_STEEL
(DWH test)
dbt pods
(image :develop)
Vertica LIVE andmebaas
LIVE namespace
PodCreate DW_STEEL_*_ODS
Liquibase pods
(image :main)
ConfigMap + Secrets
keskkonna seaded Kestra LIVE
LIVE
PodCreate
Hop pods
(image :main)
PodCreate
Kohalik arendus EDW_STEEL
(EDW)
Git & CI/CD
(valikuline) kohalik arendus ja lokaalne
dbt pods
k3s/k3d + Kestra testimine
(image :main)
DWH_STEEL
(DWH)
Liquibase
Docker Desktop
CI pipeline
main branch
build image :main
dbt-vertica Feature branch Container Registry
develop branch
Python venv (JIRA task) registry.tehik.ee
CI pipeline
Hop GUI build image :develop
kohalik masin
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 Sagedus Vastutav Reeglid
vorm roll
Igapäevane Jooksvalt Tellija PJ Tööde läbiviimiseks lepib
teabevahetus Täitja PJ 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 Tellija PJ Keerulisematele küsimuste
vajadustele Täitja PJ 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 Jooksvalt Tellija PJ Projekti dokumentatsioon
dokumentatsioon Täitja PJ 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 Iganädalaselt Tellija PJ Projekti kõiki tööülesandeid
tööülesanded Täitja PJ 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 Vastavalt Tellija PJ Lepingu täitmist puudutav
puudutav vajadusele Täitja PJ ametlik teabevahetus, mis pole
teabevahetus 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 Vastavalt Tellija PJ Poolte vaheline teabevahetus,
teabevahetus vajadusele Täitja PJ 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 Valdkon Riski Riski Risk Riski Skoo Riski Vastutaj
D d kirjeldu realiseerumis i realiseerumis r (S) juhtimise a
s e tagajärg mõj e tõenäosus tegevuse
u (TN) d
(M)
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 Roll / Nimi Maht Tunnihind Maksumus
kokku
(ID) töö nimetus (h) (€/h) KM-ta (€) 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/
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:
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 A Lahenduse 1 tund 8 tundi
viga) kasutamine on
tõsiselt häiritud,
alternatiivset
lahendust ei ole
võimalik
kasutada
Keskmine (häiriv B Lahenduse 1 tööpäev 16 tundi
viga) kasutamine on
häiritud, kuid
alternatiivne
lahendus
võimaldab tööga
jätkata.
Madal (pisiviga) C Lahenduse 2 tööpäeva 40 tundi
kasutamine ei ole
häiritud, vea
ilmnemine ei
takista otseselt
lahenduse
kasutamist
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
[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.
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 Nõude sisu Seletused Digiriigi Iseteenindus Veebid Karbitoode Koostamise Testimise läbi viib
nr CFR eest vastutaja või kinnitab
1. Vastavus üldistele standarditele
1.1 Lahendus loomisel peab arvestama Kohustus- ja ootustasemel olevad nõuded tuleb V V Arendaja Projektijuht
digiriigi ristfunktsionaalsed nõudeid. rakendada.
Arhitekt
https://koodivaramu.eesti.ee/e-gov/cfr
Administraator
Testija
Erisused tuleb kokku leppida Tellija lahenduse
Turvatestija
arhitektiga.
Infoturbe
spetsialist
Standardija
1.2 Lahenduse X-tee teenused peavad https://X-tee.ee/docs/live/xroad/ V V V Arendaja Testija
vastama nõuetele.
1.3 Lahendus peab vastama Tulevase ja olemasolevate infosüsteemide platvormid V V V Arendaja Projektijuht
Sotsiaalministeeriumi IT-profiilile. (rakendusserver, andmebaas, kolmanda osapoole
Arhitekt
komponendid) ja topoloogia peavad olema loodud
kooskõlas hankes viidatud IT-Profiil versioonile. Administraator
Testija
Turvatestija
Infoturbe
spetsialist
Standardija
1.4 Lahenduse kasutajaliides peab vastama https://tehik.ee/arendusjuhendid V V Arendaja Arhitekt
dokumendis "Front-end arendusreeglid"
Testija
kirjeldatud reeglitele.
1.5 Rakendus peab olema kirjutatud https://eits.ria.ee/ V V V Arendaja Turvatestija
arvestades selle lahenduse äriprotsesside
Arhitekt
ja andmete E-ITS ja ISKE turvaklassi
nõudeid.
1.6 Veebirakenduse kasutajaliides peab https://www.w3.org/TR/WCAG22/ #39 V V V Arendaja Testija
vastama vähemalt WCAG 2.2 tasemele
CFR selgitus: WCAG 2.2 alates 05.10.2023
AA.
1.7 Veebipõhine kasutajaliides peab Valideerimiseks kasutatakse vastavaid validaatoreid: #38 V V Arendaja Testija
ühilduma täielikult standarditega HTML
https://validator.w3.org/
5 ja CSS 3.
Kui on tegu olemasoleva süsteemi edasiarendusega,
siis tuleb järgida olemas olevat HTML ja CSS
versiooni.
1.8 Allkirjastamisel tuleb kasutada Tellija https://www.tehik.ee/arendusjuhendid V V Arendaja Testija
SiGA/SiVa vahendusteenust.
Arhitekt
1.9 Rakendus peab probleemideta läbima Kui pole arenduses eraldi kokku lepitud teisiti, siis on #9 V V V Arendaja Turvatestija
OWASP ASVS baasil põhineva testi. OWASP ASVS tasemeks 2 (https://owasp.org/www-
#10
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.
1.10 Krüptoalgoritmite ja räsifunktsioonide Krüptoalgoritmite ja räsifunktsioonide kasutamisel #46 V V V Arendaja Arhitekt
kasutamisel tuleb kasutada turvalisi tuleb järgida uusimat RIA kodulehel avaldatud
Administraator
algoritme ja võtmepikkuseid. krüptograafiliste algoritmide kasutusvaldkondade ja
elutsükli uuringut. Turvatestija
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.
1.11 Andmete edastus peab olema kaitstud Autentimist ei ole vaja ainult avalike andmete V V V Arendaja Turvatestija
kasutades krüpteeritud ning vajadusel edastamisel (nt avaandmed).
Arhitekt
autenditud ja autoriseeritud kanalit.
Autentimise mehhanism tuleb kokku leppida
Tellijapoolse arhitektiga.
1.12 Infosüsteem peab kasutama serveri Kõik mahakirjutatavad ja talletatavad kellaajad tuleb #51 V V V Arendaja Arhitekt
kellaaega. salvestada UTC ajatsoonis koos ajatsooni infoga.
Administraator
Kasutajatele mõeldud kuvades tuleb kasutada sirviku
ajatsooni. Aja esitamisel tekstikujul lähtuda
standardist ISO 8601.
1.13 Süsteemi edasiarendamisel/loomisel peab Süsteemi jõudlus peab vastama kokkulepitud V V V Arendaja Arhitekt
arvestama selle võimaliku laiendamisega topoloogial eelanalüüsi ja lähteülesande käigus välja
Testija
nii andmemahtude kui ka kasutajate arvu toodud jõudlusnäitajatele.
osas.
1.14 Rakendus peab olema tehniliselt Lahenduse arhitektuuris kasutada domeenist juhitud #21 V V Arendaja Arhitekt
tükeldatud vastavalt loogilisele jaotusele. disaini ja mikroteenuste põhimõtteid.
Saadud osised peavad olema eraldi
Näiteks kui rakendus on eraldi turvakontekstidega
versioneeritavad ja paigaldatavad.
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/
1.15 Avalike e-teenuste loomisel peab https://riigikantselei.ee/valitsuslogo #36 V V V Arendaja Testija
arvestama valitsusasutusele kehtestatud
visuaalse identiteedi stiilijuhiseid.
1.16 Avalike e-teenuste loomisel peab https://veera.eesti.ee/ #36 V V Arendaja Arhitekt
arvestama Veera disainisüsteemiga.
Näiteks kasutada ja laiendada E-Gov CVI projekti
komponente:
https://e-gov.github.io/cvi/
1.17 Lahenduse loomisel peab arvestama https://digiriik.eesti.ee/koostoimeraamistik/ V V V Arendaja Arhitekt
riiklikku koostoimeraamistikuga.
Administraator
1.18 Aadressiandmete sisestamisel, kuvamisel Liidestatakse Maa-ameti ADS teenusega. #53 V V Arendaja Arhitekt
ja hoidmisel tuleb lähtuda Vabariigi
Esitluskihis on lubatud liidestada In-ADS teenusega Standardija
Valitsuse määrusest "Aadressiandmete
otsingu tarvis. Taustsüsteemides toimub liidestamine
süsteem". Testija
X-tee teenusega.
https://www.riigiteataja.ee/akt/115072023005?
leiaKehtiv
1.19 Tegevusalade andmete sisestamisel, https://www.riigiteataja.ee/akt/12910889?leiaKehtiv #54 V V Arendaja Standardija
kuvamisel ja hoidmisel tuleb lähtuda
https://emtak.rik.ee/EMTAK/ Testija
Vabariigi Valitsuse 10. jaanuari 2008. a
määrusest nr 11 "Klassifikaatorite
süsteem" ja kasutada EMTAK
infosüsteemis kehtivat klassifikaatorit.
2. Nõuded rakenduse arhitektuurile
2.1 Rakenduse, andmebaasi ja kolmanda Arendaja loodud lahenduse dokumentatsioonis (nt #7 V V V Arendaja Arhitekt
osapoole komponendid peavad olema analüüs vms) peab olema välja toodud kasutatavate
sellised, mille turbe uuenduste eluea lõpp komponentide nimetused ja versioonid. Lubatud on
(Security Support) pole teadaolevalt kasutada ka tarkvara materjalide loendit (SBOM).
vähem kui 2 aasta pärast. 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.
2.2 Rakendusserver peab võimaldama V V V Arendaja Administraator
töötamist andmebaasiserverist eraldi
serveril.
2.3 Rakendusserver peab olema Kasutaja sessioonid ei tohi olla rakenduserveri klastri V V V Arendaja Administraator
kõrgkäideldav ja horisontaalselt õla põhised.
skaleeruv.
2.4 Rakendust peab saama ilma Lahenduses ei tohi olla sisse kompileeritud V V V Arendaja Administraator
ümberprogrammeerimata liigutada absoluutseid URI-sid.
erinevate domeenide ja domeeni saitide
vahel.
2.5 Rakenduse komponentide Rakendus peab neid sealt ka kasutama (mitte V V V Arendaja Administraator
konfiguratsiooni peab olema võimalik kopeerima parameetreid käivitamisel kolmandatesse
Testija
ette anda käivitamisel. Konfiguratsiooni kohtadesse), logimise seaded võivad olla rakenduse
muudatus peab olema teostatav ilma konfiguratsioonifailist eraldi ühes
rakendust kompileerimata. 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.
Näiteks konteinerlahenduste puhul peab kasutama
keskkonnamuutuja põhiseid konfiguratsiooni
parameetreid.
2.6 Rakenduse taaskäivitus, konfiguratsiooni Tavaline käivitusaeg ei tohi ületada 30 sekundit. V V V Arendaja Testija
muutmine vms peab toimuma mõistliku
Kui rakendus vajab indekseeritud sisu ja see pole
aja jooksul.
kättesaadav, siis peab rakendus väljastama selle kohta
selge teate.
2.7 Lahenduse väliste osapoolte Kui rakendusel või mõnel selle komponendil on tihti V V Arendaja Arhitekt
komponentide konfiguratsioonid peavad kasutatav teenus ning sellel teenusel on laetav
Testija
olema puhverdatud. konfiguratsioon, siis tuleb:
Administraator
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
2.8 Kõik andmed, andmebaasid, SQL #50 V V V Arendaja Administraator
skriptid, lähtekood ja rakendus peavad
Testija
kasutama UTF-8 või UTF-16
kodeeringut.
2.9 Rakendusserveri failisüsteemi ei tohi Näiteks objektide talletuseks kasutada objektide V V Arendaja Administraator
salvestada midagi püsivaks kasutamiseks. talletamise lahendust (nt MinIO).
2.10 Ühest relatsioonilise andmebaasi Erinevate skeemide vahelised ühendused on keelatud. V V Arendaja Arhitekt
andmetabelist teise viitamisel tuleb Peab kasutama REST/SOAP/AMQP liidestust.
kasutada väliseid võtmeid (Foreign key).
2.11 Kõik välised võtmed (Foreign Key) Andmebaasis peab kasutama indekseid ja/või muid V V Arendaja Arhitekt
peavad olema indekseeritud. meetmeid, et nõuded rakenduse jõudlusele oleksid
täidetud ka tulevikus. (ühe, kolme, viie või 10 aasta
pärast – vastavalt planeeritud kasutusajale).
2.12 Tuleb kasutada päringumuutujaid SQL päringute väljakutsumisel väljastpoolt V V Arendaja Arhitekt
(Parameter Binding). 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).
2.13 Kõigis andmebaasi tabelites peab olema Kasutada tuleb vastava andmebaasisüsteemi V V Arendaja Arhitekt
defineeritud üks primaarvõti nimetamise parimaid praktikaid.
2.14 Andmebaasi objektide nimetused peavad Kasutada tuleb vastava andmebaasisüsteemi V V Arendaja Arhitekt
olema sisulised ja andma aimu nende nimetamise parimaid praktikaid.
otstarbest.
2.15 Andmebaasis defineeritakse üldjuhul Need õigused, mis on vajalikud ainult rakenduse baasi V V Arendaja Administraator
kaks või enam kasutajat: loomiseks, on eraldi välja toodud ja tuleb peale
installeerimist ära võtta. Karbitoodete puhul tuleb
Rakenduse peakasutaja, kellena
erisused läbi arutada Tellija arhitektiga.
luuakse objektid ja skeemid.
Rakenduse piiratud õigustega Lahenduse puhul, milles kasutatakse andmebaasi
kasutaja, kellena pöördub versiooneerimist, tuleb kasutada mitut andmebaasi
rakendusserver/rakendus. ühendust. Ennem rakenduse käivitumist teostatakse
andmebaasi skeemi muudatused eraldi kasutajaga.
Objektide loomiseks vajalikud õigused ja
Rakendus kasutab enda põhitööks kasutajat, kellel
ressursid on loetletud rakenduse
puudub õigus andmebaasi skeemis muudatusi
dokumentatsioonis.
teostada.
2.16 Failide hoidmise asukoht lepitakse iga Failide hoidmine klassikalises andmebaasis on V V Arendaja Arhitekt
kord kokku, kuid failid ja failide indeks kulukas ja seab kõrgendatud nõudmised ja piirangud
peavad olema replikeeritavad teise andmebaasiserveritele. Lahenduse dokumentatsioonis
asukohta. tuleb ära tuua failide hoidmise asukoht.
Näiteks objektide talletuseks kasutada objektide
talletamise lahendust.
2.17 Peab olema miinimumini viidud vajadus, Halduri haldustoimingud lepitakse Tellijaga kokku V V V Arendaja Testija
et haldur teeb haldustoiminguid otse detailanalüüsi käigus.
baasis. St rakendusel peab olema
haldusliides, mille kaudu rakenduse
haldur saab teha tavapäraseid
haldustoiminguid.
2.18 Andmebaas peab toetama nii külm- kui Ei tohi kasutada teenuseid, mis välistavad andmebaasi V V Arendaja Arhitekt
ka kuumvaru (peegeldamist) teise peegeldamist (nt "MSSQL filestream").
asukohta.
2.19 Sorteerimisreeglistik peab olema Eesti Näiteks PostgreSQL puhul et_EE. V V V Arendaja Testija
tähestikule vastav. Tõusutundlikkus peab
olema välja lülitatud. Diakriitiline
(Accent) peab olema sisse lülitatud.
2.20 Kui infosüsteemid saadavad e-kirju, Saatja ja adressaadid, pealkiri ja sisu ei tohi olla V V V Arendaja Administraator
peavad nad kasutama välist e-maili rakendusse kodeeritud, vaid on muudetavad
serverit. Kirja saatmisel peab rakendus konfiguratsioonifaili kaudu.
veenduma, et e-posti server võttis kirja
Genereeritud kirjade puhul peab tagama kirjade
vastu. E-kirjade vormindamine peab
jälitatavuse (näiteks lisada X-päise kodeeritud kirje,
järgima interneti standardeid (RFC
milles on kirjeldatud, mis protsess/skriptifail/kasutaja
5322).
kirja genereeris jms abistav info).
2.21 Konfiguratsiooniparameetrite nimed Näiteks : X_TEE_TURVASERVER, mitte XTTS või V V Arendaja Administraator
peavad olema sisulised. Kui see ei ole viitenumber, mitte vk_seb jne
võimalik, siis peab kõrval olema seletus. Testija
2.22 Infosüsteemides on eessüsteemid (front Koostöövõime raamistik 2011. Punkt 3.1. #23 V V Arendaja Arhitekt
end; presentatsiooni kiht) ja Tagasüsteemide ülesanneteks on andmete haldamine
#29
tagasüsteemid (back end; äriloogika kiht) ja võrguteenuste pakkumine. Tagasüsteemid ei tegele
arhitektuuriliselt selgelt lahutatud ja lõppkasutaja autentimise ja autoriseerimisega. #64
eraldi paigaldatavad. Lõppkasutaja autoriseerimise tagavad eessüsteemid.
Välise süsteemi tõrge tohib mõjutada ainult sellest
Rakenduse äriloogika tuleb realiseerida
otseselt sõltuvate kasutuslugude toimimist. Välise
andmebaasist eraldi sõltumatus
süsteemi taastumisel peab süsteem olema suuteline
rakenduskihis.
oma tööd jätkama taaskäivitamata.
Andmebaas ei tohi sisaldada äriloogikat, mis muudab
andmetabelites olevaid/sinna kirjutatavaid andmeid,
va trigerid, mis tekitavad logi.
2.23 Konfiguratsioonifailid peavad olema Näiteks IIS: *.config , *.resources Apache: *.conf, V V V Arendaja Administraator
vastavalt rakendusserveri tüübile .htaccess.
vaikimisi kaitstud failid/objektid.
Arendaja peab välja tooma konfifailide listi, kui neid
on mitu.
2.24 Rakenduse failid, mida kasutaja näha ei Näiteks: IIS: Bin,App_Code, App_Data, V V V Arendaja Administraator
tohi, peavad olema vaikimisi kaitstud App_Browsers, App_GlobalResources,
kaustades ja ei tohi olla veebi App_LocalResources, App_Themes,
juurkaustas. App_WebReferences, .git
2.25 Konfiguratsiooniparameetrite Kõiki parameetreid tuleks konfiguratsioonis kirjeldada V V Arendaja Administraator
taaskasutus. Erinevaid sama sisuga vaid korra, dubleerimine on keelatud.
Testija
parameetreid ei tohi konfiguratsioonis
eksisteerida.
2.26 Esitluskihist ei tohi pöörduda otse Tuleb rakendada vähemalt 3 tasandilist arhitektuuri V V V Arendaja Administraator
andmebaasi poole. (three-tier architecture).
Lõppkasutaja lokaalsesse seadmesse paigaldatud
tarkvara loeme esitluskihiks. Ka sellisel juhul ei tohi
teha lõppkasutaja seadmest otse ühendust andmebaasi.
2.27 Keskkonnapõhised muutujad peavad Näiteks WSDL ei tohi sisaldada viiteid V V V Arendaja Administraator
olema konfiguratsiooniparameetritega arendusserveritele.
Testija
seadistatavad.
2.28 Eelistada tuleb tsentraalseid Kui rakendus realiseerib ise autentimist, siis peab #30 V V V Arendaja Arhitekt
autentimislahendusi (nt Tellija SSO olema võimalik piirata ebaõnnestunud logimisi
Testija
lahendus). 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
2.29 Relatsioonilises andmebaasis võib Ei ole soovitav kasutada mingit V V Arendaja Arhitekt
kasutada vaid ISO/IEC 9075 standardiga platvormispetsiifilist lahendust, mille üleviimine
kaetud funktsionaalsusi. Lisaks ei tohi mõnele muule andmebaasiplatvormile ei ole
kasutada ka sama standardi osas 13 võimalik.
kirjeldatud funktsionaalsusi. ISO/IEC 9075 osa 13 spetsifitseerib Javas
kirjutatud programmimoodulite kasutamist
andmebaasis.
2.30 Uniform resource identifier (URI) pikkus Harilikult on piiriks 2048 tähemärki, kuid iga V V V Arendaja Administraator
ei tohi ületada ühegi lahenduse poolt lahenduse puhul tuleb seda eraldi järele uurida
Testija
toetatava sirviku maksimaalset lubatud sõltuvalt lahenduse komponentidest. Asjakohased
väärtust. viited: RFC 3986 ja RFC 7239.
2.31 Veebiteenuseid (REST, SOAP) pakkuv Näiteks WSDL puhul: Alajaotis V V V Arendaja Arhitekt
rakendus peab olema üles ehitatud nii, et definitions/types/schema:
see toetaks teenuste versiooneerimist
complexType defineerimisel tuleb sellele lisada
URL-i ja/või skeemi tasemel.
any element.
2.32 Rakendus peab olema võimeline töötama Koormusjaoturi peal kasutatakse järjestikplaanurit V V V Arendaja Administraator
koormusjaoturitega varustatud taristul. (Round Robin) päringute suunamisel. Samuti võidakse
teostada koormusjaoturil TLS ühenduse lahtivõtmist ja
uuesti kokkupanemist (SSL offload).
2.33 Sidusinfosüsteemide mittekättesaadavus Sidussüsteemi tõrge tohib mõjutada ainult sellest V V V Arendaja Administraator
ei tohi segada rakenduse töötamist. otseselt sõltuvate kasutuslugude toimimist.
Testija
Sidusinfosüsteemidega Sidussüsteemi taastumisel peab süsteem olema
andmevahetamisel tekkinud vead suuteline oma tööd jätkama rakendust taaskäivitamata.
logitakse ja kasutajat hoiatatakse.
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.
2.34 Automaatselt käivituvaid taustatöid peab Vajalik juhul, kui automaatsel käivitumisel on V V V Arendaja Testija
saama käsitsi (taas)käivitada. 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).
2.35 Kui ajastatult käivitatav taustatöö ei ole Kui lahendus töötab mitmel õlal, ei tohi tööd, mis ei V V Arendaja Administraator
mõeldud käima paralleelselt, peab selles ole mõeldud paralleelselt käima, käivituda korraga
Testija
olema realiseeritud kontrollmehhanism, mitmel õlal. Peab rakendama lukustus põhimõtet.
mis tagab, et sama taustatööd ei ole
võimalik käivitada uuesti enne, kui
eelmisena käivitatud instants on oma töö
lõpetanud.
2.36 Uue toote arenduse ja olemasolevate V V V Arendaja Arhitekt
infosüsteemide versiooniuuendustel
kasutusele võetavate tehnoloogiate ja
standardite valik tuleb kooskõlastada
Tellijapoolse arhitektiga.
2.37 Rakenduse ühenduste (s.h. andmebaasi ja Implementeeritud peab olema vähemalt V V V Arendaja Arhitekt
sidusinfosüsteemide ühendused) maksimaalsete ühenduste arvu piirang, päringu
realiseerimisel tuleb kasutada ühenduste aegumise aeg (request timeout) ja ühenduse elususe
puulimist (connection pooling). 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.
2.38 Rakenduse uuendustega kaasnevad Näiteks Liquibase või Flyway. V V Arendaja Administraator
andmebaasi muudatused tuleb
automatiseerida ja versioneerida.
2.39 Mitterelatsioonilises mudelis andmete Näiteks kui soovitakse kasutada NoSQL lahendusi V V V Arendaja Arhitekt
hoiustamine tuleb eraldi kokkuleppida. püsivaks andmete talletuseks, tuleb see kokku leppida
Tellijapoolse arhitektiga.
2.40 Mikroteenuste arhitektuuris vältida Iga teenus vastutab enda valdkonna andmete eest. Kui V Arendaja Arhitekt
ebavajalikku andmete dubleerimist. on vajadus lisaandmete jaoks, on tal võimalik
pöörduda teise teenuse poole.
2.41 Infosüsteemide vaheline andmevahetus https://www.ria.ee/riigi-infosusteem/andmevahetuse- #22 V V V Arendaja Arhitekt
toimub üle X-tee. 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.
3. Turvalisuse tagamisega seotud nõuded
3.1 Asutusesiseseks kasutamiseks mõeldud TEHIKu haldusala kasutajad ja nende rollid on V V V Arendaja Turvatestija
rakenduse kasutajate autoriseerimist peab kirjeldatud Active Directory's. Võimalik on kasutada
saama teha vastu TEHIKu keskset rollide pärimiseks TEHIK SSO teenust.
autoriseerimisteenust.
Täpsem tehniline lahendus leida koos TEHIKu poolse
arhitektiga.
3.2 Kliendi ja serveri vahel peab autenditud V V V Arendaja Turvatestija
kasutajasessioonide korral olema
sessioon krüpteeritud HTTPS-protokolli
kasutades.
3.3 Rakendus tohib kasutada vaid sessiooni V V Arendaja Turvatestija
küpsiseid (cookies). Muude küpsiste
kasutamine tuleb kokku leppida
Tellijapoolse arhitektiga.
3.4 Kui andmebaasis olevate andmete E-ITS St kõik andmemuudatused peavad baasis säilima. #55 V V Arendaja Turvatestija
tervikluse (I ehk integrity) turvaosaklass Andmete muutmisel andmeid ei kustutata, vaid
#49 Arhitekt
on S või VS, siis tuleb kõik andmebaasi tehakse uus kirje uute andmetega. Vana muudetakse
kirjed/tabelid versioneerida. 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.
3.5 Rakendusega peab kaasas olema Testandmed peavad säilitama kõik toodangu andmete V Arendaja Arhitekt
lahendus, mis suudab toota toodangu omadused (pikkuse, tüübi) ja omavahelised suhted.
andmetest testandmed, mis ei võimalda
Täpsem vajadus ja tegevusplaan tuleb koostada Tellija
siduda konfidentsiaalset informatsiooni
arhitekti ja tooteomanikuga.
päris andmesubjektiga.
3.6 Rakendus ja selle komponendid peavad Arendaja arendab arenduskeskkonnas ja annab tarne V V V Arendaja Turvatestija
võimaldama kasutada keskkondade üle Tellijale paigalduspakkidena. Tellija paigaldab
lahusust. 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.
3.7 Rakendusse ja andmetele tohib olla St rakendustes ega andmebaasides ei tohi olla V V V Arendaja Turvatestija
ligipääs vaid dokumenteeritud ja ligipääsemiseks teisi võimalusi.
tellimuses kirjeldatud teid mööda ning
dokumenteeritud autentimisprotseduure
kasutades.
3.8 Rakendus ei tohi teostada X-tee päringut Kasutajaarvutitest otse X-tee päringute tegemine on V V V Arendaja Turvatestija
otse kasutajaarvutist. arvutivõrgu tasemel kinni.
3.9 Veebipõhised välise veebilehega IIS puhul peab kasutama näiteks URL scan, apache V V V Administraator Turvatestija
rakendused peavad kasutama vahendeid, puhul modsecurity või vastavat tööriista. Lubamatud
kaitsmaks rakendust lubamatute päringud on kõik päringud, mis ei ole detailanalüüsi
päringute eest. käigus vastavalt kasutusjuhtudele ette nähtud.
Blacklistingu asemel tuleb kasutada whitelisting
põhimõtet.
3.10 Kasutaja peab saama soovi korral Rakendus peab sisenemisel näitama pärast õnnestunud V V V Arendaja Turvatestija
veenduda, kas keegi pole tema nime all sisselogimist eelmise õnnestunud sisselogimise aega.
vahepeal sisse loginud. 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.
3.11 Kõigil rakendustel peab olema Aeg peab olema muudetav koos teiste V V V Arendaja Turvatestija
konfigureeritav kasutajasessiooni konfiguratsiooniparameetritega.
aegumise aeg.
Nõue kehtib juhul, kui kasutatakse lahenduse sisest
sessiooni haldust.
3.12 Lahenduses kasutatavate küpsiste sisu Eesmärk on kaitsta kasutaja andmeid, mis on V V Arendaja Turvatestija
peab olema krüpteeritud talletatud sirviku küpsiste hulka.
3.13 LDAP lahenduse (nt Active Directory) Näiteks: konto on lukus, parool aegunud, konto #30 V V V Arendaja Turvatestija
kasutamisel peab rakendus kasutama aegunud, paroolipoliitika jne.
kontoga kaasnevaid
piiranguparameetreid.
3.14 Tagada tuleb rakenduse rollide lahusus. Peakasutajal ja tavakasutajal on erinevad V V V Arendaja Turvatestija
tööülesanded. Rollide/õiguste kirjeldus peab lähtuma
detailanalüüsist ja kasutusjuhtudest.
3.15 Arendus peab olema orienteeritud Toodangukeskkonnas mittevajalikud V V V Arendaja Turvatestija
toodangukeskkonnas toimimiseks. 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)
3.16 Kui rakenduse tervikluse turvaosaklass See tagab, et tõestusväärtusega andmeid ei saaks V V V Arendaja Turvatestija
on T3, peavad tõestusväärtust omavad märkamatult kustutada.
andmed olema kas ajatembeldatud,
Konkreetne lahendus tuleb kokku leppida Tellija
digiallkirjastatud või digitembeldatud
arhitektiga.
ning krüptoaheldatud.
3.17 Kui rakenduses on S3 Konkreetne lahendus tuleb kokku leppida Tellija V V V Arendaja Turvatestija
salastatuse astmega andmeid, peavad arhitektiga.
need olema nii transpordi ajal ja ka
salvestatult alati krüpteeritult.
3.18 Rakendus peab võimaldama hõlpsalt Krüptograafiat kasutav rakenduskood ei tohi V V V Arendaja Turvatestija
välja vahetada aegunud ja ebaturvalise nimeliselt välja kutsuda krüptograafilisi algoritme,
krüptoalgoritmi. 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.
3.19 Rakenduse andmebaasi krüpteerimisega Andmebaasides kasutatavad V V V Arendaja Turvatestija
seotud andmeväljad peavad olema krüpteerimisfunktsioonidest tingitud lisaväljad peaksid
muudetava pikkusega. olema muudetava pikkusega, et formaati muutmata
saaks kasutada teistsuguste parameetritega
krüpteerimisalgoritme.
3.20 Lahendus peab olema kaitstud HTMLi OWASP soovitab kasutada DOMPurify lahendust #44 V V V Arendaja Arhitekt
süstimiste eest. HTMLi saneerimiseks Turvatestija
4. Logimine
4.1 Logimiseks tuleb kasutada standardseid Näiteks Java raamistikku log4j, SLF4J, logback; V V V Arendaja Arhitekt
komponente kogu logiahela ulatuses. transpordiks syslog, Elastic Beats; logi formaadiks
Administrator
JSON. Logi peab olema loetaval tekstilisel kujul, et
logikirjeid saaks töödelda masinmõistetavalt ja
inimloetavalt.
4.2 Peab kasutama logikomponenti ja peab Seletus: Näiteks peab saama muuta logimise taset ja V V V Arendaja Arhitekt
olema võimalik juhtida logikomponendi logimise formaati.
Administraator
seadistusi.
Testija
4.3 Logisündmused peavad olema loogiliselt Auditlogi (Seansilogi, tegevuslogi) - info #41 V V V Arendaja Arhitekt
eristatavad. sisselogimiste, väljalogimiste ja seansi aegumiste
Administraator
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
4.4 Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida, kui V V V Arendaja Arhitekt
ei ole nõutud teisiti.
Testija
4.5 Logides peab olema maksimaalselt üks V V Arendaja Administraator
sündmus ühel real.
Testija
4.6 Logikirje peab olema JSON formaadis. V V Arendaja Arhitekt
Testija
4.7 Logiväljade nimed peavad olema Samatüübilised logiväljade nimed peavad olema V V Arendaja Arhitekt
normaliseeritud ja tuleb rakendada ühtsed üle logi. Infoturbespetsialist
Elastic Common Schema
https://www.elastic.co/guide/en/ecs/current/ecs-
spetsifikatsiooni.
reference.html
4.8 Rakendus peab logima kasutaja edukat ja Logima peab ka autentimise ebaõnnestumise koos V V V Arendaja Arhitekt
ebaedukat autentimist ja sessiooni põhjusega (vale juurdepääsumandaat, aegunud konto
Testija
lõpetamist, kasutaja IP-d ja jne). Logida tuleks IP-aadress, meetod ja kui võimalik
autentimismeetodit. 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.
4.9 Üle terve logi peab olema kasutaja Tegevuste sidumiseks peab olema võimalik logikirjeid #17 V V V Arendaja Arhitekt
sessiooni käigus tehtud tegevusi või sama siduda ühise välja abil. Selleks ei sobi kellaaeg, IP ega
Testija
sündmust võimalik siduda loogiliselt isikukood. Sobib näiteks unikaalne ID, mis ei tohi olla
kokku. 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.
4.10 Andmete Logikirjes peab sisalduma piisavalt informatsiooni, et V V V Arendaja Testija
loomise/vaatamise/muutmise/kustutamise vastata küsimustele kes?, mida?, kus?, kust?, millal?,
Turvatestija
tegevused peavad olema kajastatud kuidas? ja tulemus.
logides. Logida tuleb ka päringud, mille Infoturbespetsialist
Konkreetne detailsus ja tehniline lahendus tuleb
vastus on puhverdatud.
kokkuleppida Tellija arhitektiga. Näiteks on mõistlik
luua audit teenus, mis annab vastavale rollile
võimaluse näha ja auditeerida tegevusi.
4.11 Administraatorite ja haldurite poolt Lahendus peab tagama, et administraatorid/haldurid ei V V V Arendaja Infoturbespetsialist
tehtavaid andmete vaatamised, saa andmete vaatamise, muutmise logimist ise (ka
Administraator Testija
muutmised sh kustutamised (ka otse tavakasutajate logimist) deaktiveerida või logisid
baasis) tuleb logida. Muutmise puhul kustutada/muuta.
tuleb logida nii uus kui ka vana väärtus.
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.
4.12 Süsteemsed logid ei tohi sisaldada Tulenevalt GDPRist ja logi sündmuse subjekti V V V Arendaja Arhitekt
otseseid isikuandmeid. õigustest, ei tohi logide igapäevane analüüsimine ja
Testija
jälgimine riivata sündmuse subjekti õigusi.
Turvatestija
Näiteks kasutada kasutaja nime ja tunnuse asemel
tema süsteemset ID'd. Lahendus peab sisaldama Infoturbespetsialist
võimalust ID ümberpööramist reaalseteks andmeteks.
Antud tegevus peab olema auditeeritav.
Konkreetne detailsus ja tehniline lahendus tuleb
kokkuleppida Tellija arhitektiga.
4.13 Kui parameetri väärtus on tühi, tuleb see Näiteks NULL V V Arendaja Testija
logis märkida asendusväärtusega.
4.14 Logis tuleb kõik mittekuvatavad (non- Näiteks reavahetused -> \n, non-printable sümbolid - V V Arendaja Testija
printable) sümbolid kodeerida. 0x00..0x1f, 0x7f..0xff.
4.15 Rakendus peab logima kõiki rakenduses Logi sisaldab minimaalselt vea tekkimise aega, V V V Arendaja Administraator
tekkivaid tehnilisi vigu. veakoodi, veakirjeldust (stack trace, traceback vms),
Testija
võimalusel kasutaja andmeid, HTTP-, GET- ja POST-
parameetreid ja nende väärtusi. Logimise
detailsusrežiimi (info, warning, errog, debug) peab
saama muuta.
4.16 Rakendus ei tohi X-tee päringuid V V V Arendaja Administraator
salvestada rakenduse logis. Logis peab
Testija
olema X-tee tunnus (ID), et saaks siduda
X-tee logiga.
4.17 Rakenduse funktsionaalsuse kirjeldusega Mida logitakse, kuidas sündmused on logis jagatud, V V V Arendaja Arhitekt
tuleb luua logimise dokumentatsioon ja logiridade näited.
Administraator
loginäidised. Koos funktsionaalsuse
arendamisega tuleb luua ka loodava Infoturbespetsialist
funktsionaalsuse logimine ja selle
dokumentatsioon. Dokumentatsioon peab
sisaldama logis kasutatud
klassifikaatorite kirjeldusi.
5. Testimine
5.1 Rakenduse kõik üleantavad versioonid Testitulemused tuleb edastada Tellijale koos rakenduse #12 V V V Arendaja Testija
peavad enne Tellijale üle andmist olema üleandmisega. Vaata lisaks nõuet 5.2 ja 5.3.
testitud.
Testid peavad olema käivitatavad Tellija pideva
integreerimise (CI) keskkonnas (nt Gitlab) ning olema
dokumenteeritud, kuidas teostada testide seadistamist
ja manuaalset käivitamist.
5.2 Lahendus peab olema minimaalselt 75% Käivitatakse Tellija pideva integreerimise (CI) #12 V Arendaja Arhitekt
ulatuses kaetud automaatsete keskkonnas (nt Gitlab) ja kaetust raporteeritakse
#35 Testija
komponenditestidega (unit test). lähtekoodi analüsaatoris (nt SonarQube).
5.3 Lahendus peab olema minimaalselt 50% Käivitatakse Tellija pideva integreerimise (CI) #12 V Arendaja Arhitekt
ulatuses kaetud automaatsete keskkonnas (nt Gitlab).
#33 Testija
vastuvõtutestidega.
5.4 Rakendusega peab olema kaasas skript Jõudlustestide täpne kirjeldus tuleb kokku leppida #12 V V Arendaja Arhitekt
jõudlustestide tegemiseks. detailanalüüsi käigus. Arendaja peab koos
#34 Administraator
rakendusega tarnima skripti ja vajalikud tarkvaralised
vahendid kokkulepitud jõudlustestide läbiviimiseks. Testija
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.
5.5 Testimine toodangu andmetega on Testimiseks tuleb luua vastavad andmekooslused, et V V Arendaja Arhitekt
keelatud. tagada tervik voo testimise võimekus.
Administraator
Testija
5.6 Enne lahenduse esmast tootesse Turbe testide teostamist ja tellimist koordineerib #9 V V Arendaja Arhitekt
lansseerimist peab olema teostatud Tellijapoolne testija esindaja. Samuti tuleb kokku
#10 Administraator
turbetestid ja seal välja toodud leppida põhimõtted, millistel juhtudel turbe testi tuleb
probleemid lahendatud. uuesti teostada. Testija
Parendused ja lahendused tuleb kokku leppida Tellija
arhitektiga.
6. Monitooring
6.1 Rakendusel peab olema masinloetav Testlehe kättesaadavus erinevatest arvutivõrkudest #16 V V Arendaja Arhitekt
tervise testleht (health check) JSON peab olema konfigureeritav. Testleht peab uuendama
Administraator
kujul. 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.
6.2 Rakendusel peavad olema elususe ja Näiteks java Spring raamistiku puhul kasutada #16 V Arendaja Arhitekt
tööks valmiduse otspunktid. actuatori võimekust. Konteinerite orkestraatori kiht
Administraator
teostab nende järgi otsuseid. Antud lehekülgede
sisuline poole peab kajastuma ka tervise testlehel.
6.3 Rakendus peab pakkuma monitooringu Tuleb rakendada OpenMetrics spetsifikatsiooni. #16 V V Arendaja Arhitekt
lehte, kus leidub informatsioon
Monitooringu leht peab välja kuvama ka testlehel Administraator
rakenduse funktsionaalsuse toimimise
kuvatud komponentide olukorda.
kohta.
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/
7. Nõuded rakenduse lähtekoodile
7.1 Lähtekoodi kommentaarid peavad kõigis NB! Nõuet ei arvestata arendustarkvara poolt #2 V V Arendaja Arhitekt
lahenduse kihtides (rakenduse enda kood, automaatselt genereeritavate koodilõikude puhul –
andmebaas jne) olema kirjutatud inglise neid ei ole vaja tõlkida. Samuti ei rakendata nõuet
keeles. 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.
7.2 Lähtekoodi genereeritud Rakenduse kood peab olema piisavalt hästi #2 V V Arendaja Arhitekt
dokumentatsioonid peavad olema selged, dokumenteeritud, et erialast haridust omav
arusaadavad ja sisuliselt kirjeldama tarkvaraarendaja on võimeline süsteemile
vastavat koodi, mille juures nad on. jätkuarendusi teostama.
Lähtekoodist genereeritava
Rakendama peab dokumenteerimisel
dokumentatsiooniga tuleb katta kõik
programmeerimiskeele parimaid praktikaid.
avalikud (public) meetodid ja
funktsioonid. Näiteks tarkvara, mis on kirjutatud Java keeles, peab
kasutama javadoc põhimõtteid ja võimekust.
7.3 Muutujate, tüüpide ja funktsioonide Tuleb rakendada Clean Code põhimõtteid. Kui #2 V V Arendaja Arhitekt
nimed peavad olema sisulised ja andma muutuja nimetus vajab kommentaari, siis pigem muuta
aimu nende otstarbest. muutuja nimetust kommenteerimise asemel.
Näiteks muutujate nimed peavad olema selged ja
arusaadavad.
Hea näide muutujast: elapsedTimeInDays
Halb näide muutujast: etid
7.4 Koodis kasutatavad konstandid ja Nt Javas identifikaator --> ID V V Arendaja Arhitekt
lühendid tuleb kirjutada suurte tähtedega,
lähtudes kasutatava
programmeerimiskeele parimast
praktikast.
7.5 Koodis kasutatavaid konstante ei tohi V V Arendaja Arhitekt
selle kasutamise kohta väärtusena
hardcode'da – need tuleb defineerida
muutujatena ja kasutada läbi nende.
7.6 Koodis defineeritud andmetüübid peavad N:Isik; Menetlus; jne. Andmebaaside V V Arendaja Arhitekt
olema nimetava käände ainsuses. Kõik struktuurikirjeldustes/andmemudelis ei tohi kasutada
andmemassiivid tuleb nimetada nimetava täpitähti.
mitmuses (st igasugu collectionid, arrayd,
jms).
7.7 Andmetabelites sisalduvad võõrvõtmed Kasutada tuleb konkreetse andmebaasisüsteemi V V Arendaja Arhitekt
peavad nime järgi seostuma tabeli ja nimetamise parimaid praktikaid. Nt kui tegu on
väljaga millele need viitavad. tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’
oleks: Isikud.ID=Autod.Isik_ID
7.8 Andmebaasi väljade pikkused tuleb Selle asemel, et eraldada väljale x baiti, tuleb eraldada V V Arendaja Arhitekt
kirjeldada sümbolites, mitte baitides. x tähemärki. (Instead of allocating x bytes of storage
for the field, x chars of storage must be allocated).
7.9 Kui kokku pole teisiti lepitud, siis https://google.github.io/styleguide/ V Arendaja Arhitekt
rakenduse kood peab olema kirjutatud
Kui tarkvara keelel puuduvad Google stiili juhised,
vastavalt Google stiili juhendile.
siis tuleb need kokku leppida Tellija arhitektiga
enne kodeerimist.
7.10 Koodi valideerimiseks kasutatakse Üleantavas koodis ei tohi olla kriitilisi ja kõrgemaid #10 V V Arendaja Arhitekt
minimaalselt Tellija lähtekoodi probleeme.
#40
analüsaatorit.
IT profiil: Lähtekoodi analüüs
7.11 Kasutuses mitteolev kood tuleb Erandina on lubatud koodi osad, mis on valmis tehtud, V V Arendaja Arhitekt
rakenduse lähtekoodist kõrvaldada. aga ei ole veel kasutusse rakendatud ja on peidetud nn.
funktsionaalsuste lippude (feature flag) taha.
7.12 Arendamisel kasutatakse DRY ja SOLID http://en.wikipedia.org/wiki/Don%27t_repeat_yourself V V Arendaja Arhitekt
printsiipe. http://en.wikipedia.org/wiki/SOLID_(object-
oriented_design)
7.13 Üleantavas koodis ei tohi olla paroole, Kehtib ka siis, kui need on välja kommenteeritud. #28 V V Arendaja Arhitekt
mida on kasutatud arenduse käigus. Kõik sellised paroolid tuleb asendada fraasiga
#63
“<password>“.
7.14 Üleantavas koodis ei tohi olla Kui CVE ei ole lahenduses rakendatav ehk tegu on #10 V V Arendaja Arhitekt
komponente, mille CVSS punktid on 7 ja lahenduse mõistes vale-positiivsega, siis võib
kõrgemad ning CVE on rakendatav. 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.
7.15 Üleantava lahendusega peab olema SBOM ehk tarkvara materjalide loend. Mõistlik on V V Arendaja Arhitekt
kaasas viis SBOM genereerimiseks. SBOM genereerimine viia üheks järjepideva
integratsiooni voo sammuks.
SBOM publitseerimine ja analüüsimine tuleb kokku
leppida Tellijapoolse arhitektiga.
https://www.sbom.com/
7.16 Tehniliste komponentide API'del Näiteks REST API'de puhul kasutada OpenAPI #20 V Arendaja Arhitekt
eksisteerib automaatselt genereeritud spetsifikatsiooni.
dokumentatsioon.
https://www.openapis.org/
8. Andmekvaliteet
8.1 Andmekorjel kasutatakse Vabatekstivälju tuleb vältida. #61 V V V Arendaja Arhitekt
klassifikaatoreid ja loendeid, kus need on
Testija
olemas.
8.2 Tekstiväljad on mõistliku suurusega. Varchar N tähemärki, kus N on ratsionaalne kaalutlus, V V Arendaja Arhitekt
kui suur lahter võib olla; vältida text/long-varchar
kasutust, kui see pole hädavajalik.
8.3 Rakendus peab automaatselt eeltäitma Välja arvatud logimisvormi lahtrid autentimisel. V V Arendaja Testija
kõik võimalikud andmeväljad, kui need
Näiteks: kirje sisestamise kuupäev, kasutaja nimi,
andmed on varem riigile esitatud või kui
sünnikuupäev jne
nende väärtused on võimalik
automaatselt arvutada.
8.4 Lahenduses peab olema tagatud Kasutaja sama tegevuse kordamisel ei tohi tekkida V V Arendaja Arhitekt
idempotentsus. lahendusse andmeid topelt.
Testija
Näiteks "salvesta" nupu korduval vajutusel ei tohi
tekkida dubleeritud andmeridu.
8.5 Analüüsi tulemusena ja enne esimese Peab olema dokumenteeritud projekti põhi #58 V Arendaja Arhitekt
arendusetapi algust peab infosüsteemi dokumentatsiooni juures. Dokument tuleb hoida
kohta olema koostatud kontseptuaalne ajakohane.
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.
8.6 Enne igat arendusetapi algust peab Peab olema dokumenteeritud projekti põhi #58 V Arendaja Arhitekt
infosüsteemi kohta olema koostatud dokumentatsiooni juures. Dokument tuleb hoida
loogiline andmemudel ehk olemi-suhte ajakohane.
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
mittekohustuslik (NULL/ NOT NULL),
semantika ehk andmete tähendus.
8.7 Füüsiline andmemudel peab iga Igal skeemil, tabelil ja veerul on kommentaar #58 V Arendaja Arhitekt
iteratsiooni lõpus või tarne tähtajaks selle andmekirjeldusega, mis vastab loogilise andmemudeli
iteratsiooni või tarne ulatuses sisaldama kirjeldusele.
lisaks ajakohasele kontseptuaalsele ja
loogilisele andmemudelile ka
andmekirjeldusi andmebaasis.
9. Kasutajaliides
9.1 Kasutajaliidese kõik disainiotsused V V V Arendaja Projektijuht
peavad olema kooskõlastatud Tellijaga
enne nende realiseerimist.
9.2 Veebipõhine kasutajaliides peab olema Minimaalselt Microsoft Edge, Mozilla Firefox, V V V Arendaja Testija
kasutatav enamlevinud Chrome ja Safari arenduse testimise hetkel tootja poolt
veebibrauseritega, sh nutiseadmetel toetatud versioonid.
(Android, IOS).
Täpsemad nõuded dokumendis "Front-end
arendusreeglid".
9.3 Rakenduse värviskeemi ja logo Kui tegemist on struktuurfondide projektiga, on lisaks V V Arendaja Testija
kasutamine peab vastama Tellija nõutud ka vastav SF sümboolika. Tellija ametlikud
ametlikule visuaalsele identiteedile (CVI) CVI esitluspõhjad, logo kasutusjuhend ja kõik logod
ja disainijuhistele (UIG). (ka jpg-na) küsida Tellijalt.
9.4 Kasutajaliidese kõik osad ja teated Kui soovitakse juurde eraldi ka muid keeli, siis see on V V V Arendaja Testija
peavad olema eestikeelsed. spetsifitseeritud hankedokumentides.
9.5 Sisemiseks kasutamiseks tehtav Toetatud peavad olema töökohaprofiilis loetletud V V Arendaja Testija
rakendus peab olema graafiliselt resolutsioonid.
skaleeruv ja mugavalt kasutatav
Ühegi nimetatud resolutsiooni korral ei tohi tekkida
Tellija töökohaprofiilis loetletud
horisontaalset kerimisriba.
resolutsioonides.
9.6 Kasutajaliideses toiminguni (põhi- ehk Kõik rakenduse kasutajaliidesest tehtavad toimingud V V Arendaja Testija
enamkasutatavad tegevused) tohivad üksteisest olla maksimaalselt 3 hiirekliki
navigeerimiseks peab kehtima 3 kliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud
printsiip, väljalogimiseks 1 kliki saama. Väljalogimise nupp/link peab olema ühe kliki
printsiip. kaugusel ja arusaadavas/intuitiivses kohas.
9.7 Kasutajaliides peab alati küsima V V V Arendaja Testija
kinnituse andmete kustutamise ja
massmuutmiste kohta kui just teisiti
kokku pole lepitud.
9.8 Rakenduse kasutamisel tekkinud veale Veateated peavad olema sellised, mis võimaldavad IT- V V V Arendaja Testija
peab kasutajaliides vastama kasutajale abil võimalikult lihtsalt tuvastada vea olemuse ja
eestikeelse kasutajasõbraliku veateatega, asukoha.
mis sisaldab ka vea koodi. Veateated
peavad olema hallatavad.
9.9 Kasutajaliides peab olema ilma Uue keele lisamine peab olema teostatav V V Arendaja Testija
rakenduse koodi muutmata tõlgitav teise konfiguratsiooni failist või administreerimisliidesest.
keelde, v.a kui ei ole teisiti kokku lepitud.
Konkreetne lahendus tuleb kokku leppida
Tellija arhitektiga.
9.10 Rakenduse kasutajaliides peab teavitama Etteteavitamise aeg peab olema konfigureeritav. V V V Arendaja Administraator
kasutajat ette sessiooni aegumisest.
Testija
9.11 Kui vormile sisestatakse mahukaid Näiteks kui vorm koosneb paljudest väiksest V V Arendaja Testija
andmevälju, peab kasutajaliides kokku andmeväljadest (nt taotlus), siis jagatakse vorm
lepitud ajavahemike järel salvetama välja etappideks ning salvestatakse vastava etapi lõpus.
sisu, et sessiooni aegumisel või võrgu
katkestuse korral juba sisestatud andmed
ei kaoks.
9.12 Interaktiivsete vormide puhul (näiteks V V Arendaja Testija
faili üleslaadimine) ei tohiks lehe
värskendamisega tegevust korrata (faili
taas üles laadida, andmeid saata, avaldust
esitada).
9.13 Esilehel (sisselogimata) ja pärast kasutaja Näiteks võimalikud teavitused: mingi süsteemi osa on V V Arendaja Testija
sisselogimist peab olema lihtne võimalus vigane, tuli mingi uus funktsionaalsus, hetkel on
teavitada kasutajat muudatustest või hooldus, uuendage isikuandmeid jne.
probleemidest. Teavitus peab olema
Mõistlik on hooldusteate võimekiust juhtida
halduri poolt lihtsasti lisatav ja kasutajale
taustteenuse abil. Näiteks läbi esitluskihi jaoks loodud
märgatav.
seadete REST liidese.
10. Dokumentatsioon
10.1 Lõppkasutajatele ja avalikkusele Erandiks võivad olla kolmanda osapoole V V Arendaja Projektijuht
suunatud rakenduse dokumentatsioon komponentide (mis pole kirjutatud Tellija jaoks)
Arhitekt
peab olema kirjutatud eesti keeles. dokumentatsioon. Samuti võib erandiks olla väliste
osapooltega seotud projektid. Erandid tuleb Administraator
kooskõlastada Tellijaga enne dokumentatsiooni
koostamist. Testija
Infoturbe
spetsialist
10.2 Lahendus kirjeldatakse RIHA määruse https://www.riigiteataja.ee/akt/12933746? #57 V Arendaja Projektijuht
nõuete kohaselt. leiaKehtiv#para6
Projektijuht
Tellija RIHA
haldur
10.3 Rakenduse dokumentatsioon peab Dokumentatsioon peab olema versioneeritud, V V Arendaja Projektijuht
vastama dokumendis "Nõuded muutmiskuupäevadega, autori nimedega, korrektse
Arhitekt
infosüsteemi dokumentatsioonile" keelekasutusega, selge struktuuriga.
kirjeldatud nõuetele. Dokumentatsiooni detailsus peab olema piisav, et Administraator
sõltumatu kolmas tehnliste IT baasteadmistega isik
suudaks dokumendist vajalikke järeldusi teha (st Testija
dokument peab olema arusaadav sellele isikule, kuid
Infoturbe
näiteks paigaldusjuhise järgi toimetades ei pea ta
spetsialist
ebaõnnestunud tarnele teostama veaanalüüsi).
Täpsemad nõuded dokumendis "Nõuded infosüsteemi
dokumentatsioonile".
10.4 Rakenduse dokumentatsioon peab Esialgne kirjete mahu hinnang peab tulema V V Arendaja Projektijuht
sisaldama tabelite-andmete-logide mahu lähteülesandest, ning täpsustuma eel- ja detailanalüüsi
Arhitekt
kasvu arvestuslikku hinnangut rakenduse käigus. Mahuhinnang peab sisaldama ka logide
sihipärase kasutamise korral ettenähtud säilitamise, arhiveerimise tähtaegu. Administraator
arvu kasutajate poolt. (MB/GB
kuus/aastas). Infoturbe
spetsialist
10.5 Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki muudatusi eelmise V V V Arendaja Projektijuht
tooma versiooni muudatuse kirjeldused ja uue versiooni vahel.
(release notes).
10.6 Arendaja loodud lahenduse V V Aremdaja Arhitekt
dokumentatsioonis (nt detailanalüüs vms)
Administraator
tuleb välja tuua kasutatavad krüpto- ja
räsialgoritmid, nende võtmepikkused,
kasutuskohad, sh TLS sertifikaatide
kasutuskohad.
11. Versioonihaldus
11.1 Kogu rakenduse testimiseks, koolituseks Arendajale antakse selleks õigused Tellija #1 V V Arendaja Arhitekt
või implementeerimiseks üle antav versioonihalduse repositooriumi, kus ta peab hoidma
Administraator
lähtekood ja tarkvarapaketid peavad oma erinevaid versioone. Versioonihalduse
olema versioneeritud. Kasutama peab repositooriumi juurdepääsutaotlus esitatakse Tellija
Tellija versioonihalduse ja tehiste kasutajatoele läbi projektijuhi.
(artifaktide) repositooriumi.
11.2 Arendaja peab veenduma, et teeb Hea tava on, et paralleelse arendamise puhul võetakse V V Arendaja Arhitekt
muudatusi aktuaalsesse koodi. igal hommikul versioonihalduse repositooriumist
Administraator
viimane seis koodist.
11.3 Nii arendamisel kui ka hoolduslepingute Arendajale antakse selleks õigused Tellija tööde ja V V Arendaja Projektijuht
korral kasutatakse Tellija tööde ja veahalduse keskkonda.
veahalduse keskkonda.
Veahalduse keskkonda juurdepääsutaotlus esitatakse
Tellija kasutajatoele läbi projektijuhi.
11.4 Versioonihaldusesse muudatuste https://www.conventionalcommits.org/ V Arendaja Arhitekt
üleslaadimisel kasutada
üleslaadimissõnumis Conventional
Commits stiili.
12. Paigalduspaketi kooste
12.1 Rakendus on versioneeritud kasutades A.B.C kujul, kus C on veaparandus, B on #15 V Arendaja Arhitekt
semantilise versioneerimise põhimõtet. funktsionaalne uuendus, mis töötab ka vanematel
Administraator
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/
12.2 Juhul kui versioonihalduse keskkond ei Räsialgoritmiks tuleb kasutada SHA256. Linuxi V V Arendaja Administraator
paku paigalduspaketile kontrollsumma käsurealt kontrollkoodi koostamiseks: $ sha256sum
(checksum) automaatset koostamist, siis filename [filename2] ... > kontrollkood.sum.
koostatakse kontrollsumma arendaja
poolt ja pannakse eraldi .sum failina
tarnele kaasa.
12.3 Tarnitava lahenduse koosseisus üleantava Näiteks võib lahenduse paigalduspaketi koosteprotsess V V Arendaja Projektijuht
lähtekoodiga peavad kaasas olema ette näha, et käivitada tuleb rida shell-käske või
Administraator
kirjeldused sellest paigalduspaketi võivad lahenduse koosseisus olla valmis (ant, ..)
koosteks. koosteskriptid või mistahes muu moodus
paigalduspaketi tekitamiseks.
Eelistatud on kasutada Dockerfile ja Gitlab töövooge.
12.4 Kooste kirjelduste alusel valmiv Näiteks: kompileeritavate keelte puhul ei tohi V V Arendaja Arhitekt
paigalduspakett tohib sisaldada ainult sisaldada lähtekoodi, kui see pole vajalik rakenduse
Administraator
minimaalse rakenduse käitamiseks käitamiseks.
vajamineva failikomplekti.
12.5 Kooste kirjelduste alusel valmivat Näiteks ei tohi tekitada olukorda, kus rakenduse V V Arendaja Administraator
paigalduspaketti peab olema võimalik jooksutamiseks uues serveris tuleb see tingimata just
liigutada erinevate masinate vahel. sealsamas kokku kompileerida.
12.6 Rakenduse kõik sõltuvused peavad olema #4 V V Arendaja Arhitekt
kompileerimisel saadavad Tellija tehiste
repositooriumist.
12.7 Andmebaasi paigalduse skriptid ei tohi Administraator tahab veenduda skripti sisus. V V Arendaja Administraator
olla kompileeritud.
12.8 Rakenduse lähtekoodi juures peab Tellijal peab olema võimalik suuri pingutusi tegemata V V Arendaja Arhitekt
leiduma skriptid rakenduse keskkonnast ja keskkonna erinevusi vältides teha rakendusest
sõltumatult (konteinerlahenduses) kokku paigaldatav pakk.
kompileerimiseks.
12.9 Rakenduse lähtekoodi juures peab Vajadusel peab konteinerlahendus käivitama ka V V Arendaja Arhitekt
leiduma skriptid rakenduse lokaalselt rakenduse muud sõltuvused (näiteks andmebaas).
mõnes konteinerlahenduses (Docker) See on Täitjale uue meeskonnaliikme liitumise
käivitamiseks. lihtsustamiseks ja Tellijale võimalus suuri pingutusi
tegemata süsteemi testimiseks.
12.10 Paigalduspakett koostatakse Tellija #13 V V Arendaja Arhitekt
pideva integratsiooni (continuous
integration - CI) ja paigaldus (continuous
deploy - CD) arendus keskkonnas.
12.11 Kubernetesel (K8s) orkestreeritavate https://helm.sh/ V V Arendaja Arhitekt
lahenduste paigalduste jaoks tuleb luua
Helmi jaoks kasutatava malli annab Tellijapoolne Arhitekt Administraator
Helm chart.
arhitekt.
12.12 Kubernetesel (K8s) orkestreeritavate https://kubernetes.io/docs/tasks/run- V V Arendaja Arhitekt
lahenduste paigalduste jaoks tuleb luua application/horizontal-pod-autoscale/
Arhitekt Administraator
vajalikud automaatsed laienemise
reeglid.
„Andmeladude olemus ja selle funktsioonid“
Selgitav juhis
Majandus- ja Kommunikatsiooniministeerium
14.04.2023
1 / 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
2 / 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
3 / 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
4 / 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ÜM artiklid 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.
5 / 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.
6 / 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.
7 / 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.
8 / 21
täita. Seega tekivad tahes tahtmata andmed erineval kujul, kuid see ei tähenda, et tegemist oleks
lubamatu koopiaga.
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.
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
9 / 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.
10 / 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.
11 / 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.
12 / 21
Järgnevalt ilmestame kasutusviiside erinevaid juhte.
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).
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 Näiteks kui andmelao andmed on anonüümselt olemas, siis võib
anonüümitud ja justkui ka siin näha ette erisuse andmelao anonüümitud andmetele ehk
seetõttu eraldi reguleerimist tuuagi välja, et peetakse ka anonüümitud andmeladu mille
ei vaja, ei ole päris õige. Kui andmed on „x“ tähtajani. Näiteks on andmekogul ühed
teave tekib (andmed) ja see eesmärgid – loa taotlused, menetlused. Kui load on väljastatud
kantakse ja säilitatakse ja kõik menetlused lõppenud ja neid hoitakse näiteks seoses
andmekogus, tuleks seegi vaidlustamisvõimalustega vaid viis aastat, siis võib teatud
selgelt reguleerida. Toome faktiliste andmete säilitamine olla põhjendatud ka statistikaks
pikemalt, et kujundada valdkondlikku poliitikat. Nii täidavad
kõrval sellekohase näite.
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.
13 / 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)
14 / 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 ..
15 / 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 4 1,
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.
16 / 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
31
privaatsustehnoloogiate rakendamisel. 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.
17 / 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
(5) Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja
teiste isikutega (AvTS § 439 lg
riigi infosüsteemi kuuluvate andmekogude vahel toimub läbi riigi
6).33 infosüsteemi andmevahetuskihi.
(6) Käesoleva paragrahvi lõikes 5 toodu ei piira andmevahetust
infosüsteemide andmevahetuskihil muude juriidiliste isikute
vahel.
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.
18 / 21
vahele, vaid võimaldaks X-teed kasutada ka avalikus sektoris jooksutatavate infosüsteemide
vahel ning samuti erasektoris.
Suurema õigusselguse huvides võiks tulevikus tä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.
19 / 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 § 59 2 lg 1,
https://www.riigiteataja.ee/akt/110102022004#para59b2.
20 / 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.
21 / 21