Pöördumine

Dokumendiregister	Tervise- ja heaolu infosüsteemide keskus
Viit	3-9/4652-1
Registreeritud	21.07.2025
Sünkroonitud	22.07.2025
Liik	Väljaminev kiri
Funktsioon	3 Finantsarvestus ja asutuse varade haldus
Sari	3-9 Riigihankelepingud
Toimik	3-9/2024
Juurdepääsupiirang	Avalik
Juurdepääsupiirang
Adressaat	Telia Eesti AS, telia
Saabumis/saatmisviis	Telia Eesti AS, telia
Vastutaja	Epp Laanepõld (TEHIK, Äriteenuste osakond, Heaolu valdkond)
Originaal	Ava uues aknas

Dokument on kokkuvõtte tegemiseks liiga mahukas (180238 tm).

Failid

Lisa 1 - Tehniline kirjeldus.pdf

Lisa 2 - Hankelepingu projekt (1).pdf

Sotsiaalkindlustusameti infosu_steemide ma...pdf

TK Lisa 1 - Teenuse pass SKAIS1.pdf

TK Lisa 2 - Teenuse pass SKAIS2.pdf

TK Lisa 3 - Teenuse pass STAR 2204.pdf

TK Lisa 4 - TEHIK MFN 2024.pdf

Lisa 1 - Tehniline kirjeldus.pdf

Lisa 1 - Tehniline kirjeldus

Sisukord

I. SKAIS1 arhitektuuridokument ................................................................................................... 2

1. Sissejuhatus ........................................................................................................................... 2

2. Süsteemi taust ....................................................................................................................... 2

3. SKAIS1 komponentdiagramm ............................................................................................... 2

4. Majutatavad teenuse komponendid ....................................................................................... 3

5. Välised liidestused .................................................................................................................. 3

6. Süsteemi arhitektuuris kasutatavad tehnoloogiad/tarkvarad .................................................. 3

7. Tehnoloogia maatriks ............................................................................................................ 4

8. Teenuse tehniline kirjeldus .................................................................................................... 4

9. Lokatsioonide näitlik loogiline arhitektuur ............................................................................. 8

II. SKAIS2 arhitektuuridokument ................................................................................................... 9

1. Sissejuhatus ........................................................................................................................... 9

2. Süsteemi taust ....................................................................................................................... 9

3. Paigaldusvaade ...................................................................................................................... 9

4. Rajadokument ...................................................................................................................... 14

5. Süsteemi arhitektuuris kasutatavad tehnoloogiad ................................................................ 21

6. Tehnoloogiate maatriks ........................................................................................................ 21

7. Tuleviku visioon .................................................................................................................... 23

8. Teenuse tehniline kirjeldus ................................................................................................... 23

III. STAR arhitektuuridokument .................................................................................................... 29

1. Sissejuhatus ......................................................................................................................... 29

2. Süsteemi taust ..................................................................................................................... 29

3. STAR komponentdiagramm ................................................................................................ 29

4. Majutatavad teenuse komponendid ..................................................................................... 30

5. Välised liidestused ................................................................................................................ 31

6. Süsteemi arhitektuuris kasutatavad tehnoloogiad/tarkvarad ................................................ 31

7. STAR2 ametniku rakenduse arhitektuur – mikroteenused .................................................... 31

8. Teenuse tehniline kirjeldus ................................................................................................... 33

9. Nõuded mikroteenuste arhitektuuri tehnilisele ülesehitusele ............................................... 38

10. Toodangukeskkonna näitlik arhitektuur ............................................................................ 38

IV. Lisad .....................................................................................................................................40

1. Tehnilise kirjelduse lisad on:..................................................................................................40

I. SKAIS1 arhitektuuridokument

1. Sissejuhatus

1.1. Antud dokument kirjeldab SKAIS1 infosüsteemi arhitektuuri, sisaldades antud süsteemi komponentide kirjeldust, nende omavahelist suhtlemist, paigaldusvaadet ning kirjeldust süsteemi ning teda ümbritsevate keskkondade vahel.

2. Süsteemi taust

2.1. Sotsiaalkindlustusameti infosüsteem (SKAIS) on riigi infosüsteemi kuuluv andmekogu, mida peetakse seadustest tulenevate Sotsiaalkindlustusameti avalike ülesannete täitmise eesmärgil. Täna kasutusel olev SKAIS koosneb tehniliselt neljast alaminfosüsteemist - SKAIS1, SKAIS2 ja EBS, mis moodustava omavahel kokkuseotuna ühe loogilise terviku ja mida vaadeldakse ühe tervikliku infosüsteemina.

2.2. SKAIS1 on liidestatud erinevate üleriigiliste infosüsteemidega. Andmebaasis on 3,4 miljoni isiku andmed.

2.3. Infosüsteemi SKAIS1 majutuskeskkond koosneb kolmest (test-, pre-live ja live keskkond) võrgu tasemele teineteisest lahusolevast keskkonnast. Kõiki keskkonnad on üles ehitatud sarnase arhitektuuri ja komponentidega va. testkeskkond, millel puudub vajadus teise dubleeriva õla järele. Allpool dokumendis on komponentide tasemel piisava detailsusega lahti kirjutatud SKAIS1 loogiline arhitektuuriline ülesehitus kirjeldamaks praeguse süsteemi toimimist ja võimaldamaks jätkusuutlikku arengut tulenevalt Sotsiaalkindlustusameti arenduse soovidest.

3. SKAIS1 komponentdiagramm

3.1. Järgnev skeem kirjeldab SKAIS1 infosüsteemis paiknevaid komponente ning nende vahelist suhtlust:

3.2. Veebiportaal (siseveeb) – Sotsiaalkindlustusameti ametnikele mõeldud veebirakendus, ligipääsetav ainult sisevõrgust.

3.3. MISP2 – Veebirakendus, sisaldab sealhulgas Teenuseosutaja portaali.

3.4. Turvaserver – Liidestus X-Teega (asub füüsiliselt TEHIKus). 3.5. Adapterserver – Vahekomponent x-tee turvaserveri ja andmebaasi vahel. 3.6. Andmebaas – Oracle Database Enterprise Edition, SKAIS1 andmestik.

4. Majutatavad teenuse komponendid

4.1. Andmebaas 4.1.1. Oracle Database 11g Enterprise Edition.

4.2. Veebiportaal (siseveeb) 4.2.1. Sotsiaalkindlustusameti ametnikele mõeldud veebirakendused 4.2.2. Tüüp: teenuseid pakkuv veebilehekülg 4.2.3. Kasutatud protokoll: sisevõrgu veebileht, https 4.2.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.3. Adapterserver 4.3.1. Kasutatakse x-tee teenuste vahendamiseks x-teele (ka MISP2 ja eesti.ee) 4.3.2. Tüüp: sünkroonne ja asünkroonne teenus; süsteemne taustprotsess 4.3.3. Kasutatud protokoll: integreeritud süsteemi osa

4.4. Digitempel 4.4.1. Füüsiline krüptopulk pangalinkides maksefailide allkirjastamiseks/krüpteerimiseks. 4.4.2. Tüüp: Daemon protsess 4.4.3. Kasutatud protokoll: jdbc; https; PKCS11

4.5. Pangalink 4.5.1. Pankadega andmevahetuse server. 4.5.2. Tüüp: Daemon protsess 4.5.3. Kasutused Swedbank ja SEB standard gateway tarkvara

5. Välised liidestused

5.1. Eesti.ee riigiportaal 5.1.1. Pakutakse 16 avalikku veebiteenust

5.2. Sertifitseerimiskeskus 5.2.1. digiallkirjade kehtivuskinnitus 5.2.2. Tüüp: sünkroonne teenus

5.3. EESSI 5.3.1. EL pädevate asutustevaheline andmevahetuskeskkond.

5.4. Pank 5.4.1. Väljamaksete edastamine panka 5.4.2. Tüüp: asünkroonne gateway 5.4.3. Kasutatud protokoll: SOAP

5.5. X-tee 5.5.1. Erinevate andmekogudega suhtlus 5.5.2. SKAIS1 poolt x-teel pakutavaid erinevaid teenuseid on 67; 5.5.3. SKAIS1 poolt x-teel tarbitavad erinevaid teenuseid on 82; 5.5.4. Tüüp: sünkroonne/asünkroonne 5.5.5. Kasutatud protokoll: SOAP

6. Süsteemi arhitektuuris kasutatavad tehnoloogiad/tarkvarad

6.1. Serverite operatsioonisüsteem 6.1.1. Serverite operatsioonisüsteemi tarkvarad peavad olema kaetud tootjapoolse

tarkvaratoega lepingu perioodi vältel. 6.1.2. Operatsioonisüsteem: Red Hat Enterprise Linux 7 (RHEL) / Oracle Enterprise Linux 7

(OEL). 6.1.3. Vajalikud litsentsid tagab Täitja.

6.2. Apache HTTP Server Versioon: 2.4.37

6.2.1. Konfiguratsioon ja nõuded: SSL, ID-Kaardi sertifikaadi tuvastamine (ssl konfiguratsioon).

6.2.2. Operatsioonisüsteem: Red Hat Enterprise Linux 7 (RHEL) 6.2.3. Vajalikud SSL sertifikaadid tagab Tellija.

6.3. Apache Tomcat Versioon: 9.0.82 6.3.1. Konfiguratsioon ja nõuded: - 6.3.2. Operatsioonisüsteem: Red Hat Enterprise Linux 7 (RHEL)

6.4. Oracle Database Enterprise Edition 11g Versioon: Oracle Database 11g Enterprise Edition 11.2.0.4.

6.4.1. Konfiguratsioon ja nõuded: klasterdatud andmebaas. 6.4.2. Operatsioonisüsteem: Oracle Enterprise Linux 7 (OEL). 6.4.3.Andmebaasi eeldatav stardimaht (täna olemasolev andmestik) 1TB 6.4.4. Tellija tagab 8 (kaheksa) Oracle Database Enterprise CPU litsentsi. Süsteemi

arengust tingitud vajaduse korral tagab lisalitsentsid Tellija. 6.5. Oracle Partitioning

6.5.1. Kasutatakse SKAIS1 Oracle andmebaasi partitsioneerimiseks. 6.5.2. Tellija tagab 8 (kaheksa) litsentsi. Süsteemi arengust tingitud vajaduse korral tagab

lisa-litsentsid Tellija. 6.6. IBM Websphere Application Server Community Edition Versioon: 2.1.1.6 Veebiteenuste

server. 6.7. Konfiguratsioon ja nõuded:- 6.8. Operatsioonisüsteem: CentOS 5.8

7. Tehnoloogia maatriks

Rakendus Java 8 SOAP Apache Tomcat 6.x

Oracle 11g EE Märkus

Veebirakendused x x x SafeNet eToken x X-tee adapter x x x X-tee turvaserver x Andmebaas x

8. Teenuse tehniline kirjeldus

8.1. Nõuded serveriruumile ja infrastruktuurile 8.1.1. Täitja majutab Tellija infosüsteemi kahes füüsiliselt eraldi asukohas ja eraldi

aadressidel paiknevas serveriruumis. Serveriruumid ja nendevahelised ühendused peavad paiknema Eesti Vabariigi territooriumil ja serveriruumide minimaalne nõutud geograafiline vahemaa on vähemalt 1 km.

8.1.2. Serveriruumid peavad olema spetsiaalselt ehitatud serverite majutuseks ja vastama E- ITS turbeastmele H ning standardile ANSI/TIA-942 (Telecommunications Infrastructure Standard for Data Centers) tasemele Tier 3, mööndusega, et varugeneraator ei pea olema dubleeritud.

8.1.3. Täitja tagab SKAIS1 infosüsteemile turvatud (SSL) välise andmesideühenduse kiirusega vähemalt 100 Mbps (megabitti sekundis) ja serveriruumide vahel füüsilise, turvatud (VPN) dubleeritud ühenduse kiirusega vähemalt 1 Gbps (gigabitti sekundis).

8.1.4. Andmesideühenduse (internetiteenuse) täitja peab olema Eesti Interneti SA poolt akrediteeritud.

8.1.5. Serverite ja serveriruumide vaheline ühenduse kiirus peab olema piisav, et tagada teenustaseme nõuded. Tõrke korral peab olema tagatud teenuste üle viimine teise serveriruumi teenuse nõuetele vastava aja jooksul.

8.1.6. Täitja serveriruumid peavad olema ühendatud tellija serveriruumidega läbi VPN ühenduse kiirusega vähemalt 1Gb/s. Tellija serveriruumid asuvad serverimajutuskeskustes kahes erinevas lokatsioonis Eesti Vabariigis.

8.1.7. Täitja peab kasutama riistvara, millel töötab ainult Tellija infosüsteem. Pakutaval riistvaral ei tohi töötada samal ajal kolmandate osapoolte infosüsteemid. Samuti ei tohi olla kolmandatel osapooltel ligipääse pakutavale riistvarale ja operatsioonisüsteemile.

8.2. SKAIS1 infosüsteemi majutus- ja tugiteenuste üldised (miinimum) nõuded 8.2.1. Täitja kohustub tagama SKAIS1 infosüsteemi kasutamise võimaluse veebikeskkonnas

ning lepingu kehtivuse perioodil kindlustama keskkondade nõuetekohase (hankedokumendis ja teenusepassis kirjeldatud) funktsioneerimise.

8.2.2. Täitja tagab SKAIS1 infosüsteemi järgmised majutus- ja tugiteenused: 8.2.2.1. Serverite, võrgu- ja salvestusseadmete ressursid. 8.2.2.2. Andmebaaside administreerimine ja monitooring. 8.2.2.3. Infrastruktuuri administreerimine ja monitooring. 8.2.2.4. Muudatuste haldus. 8.2.2.5. Konsultatsioonid ja parendusettepanekud. 8.2.2.6. Muud ühekordsed tegevused ehk lisatööd. 8.2.2.7. Teenuse lõpetamisega seotud tööd lepingu lõppemisel.

8.2.3. Infosüsteem peab olema majutatud kahes serveriruumis põhimõttel primary site ja failover site. Täitja peab kirjeldama, mis vahenditega tagatakse vajaduse korral teenuste üle viimine teise serveriruumi vastavalt käideldavusnõuetele.

8.2.4. SKAIS1 infosüsteemi Oracle andmebaaside vaheliseks andmete reaalajas sünkroniseerimiseks peab Täitja kasutatama Oracle Data Guard tarkvara. Oracle Active Data Guard tarkvara võetakse kasutusele vajadusepõhiselt, mille kasutuselevõtu tingimused lepitakse eraldi kokku teenuseosutajaga.

8.2.5. Lepingu lõppedes kooskõlastatakse andmete uude majutuskeskkonda migreerimise ja seejärel hävitamise protsess Tellija ja Täitja vahel. Andmete ülekolimise ja hävitamise järgselt vormistab majutusteenuse osutaja akti, millega kinnitatakse, et andmed on hävitatud.

8.2.6. Teenuse osutaja vahetumisel vormistatakse andmete ülekolimise (migratsiooni) läbiviimise järgselt kolmepoolne üleandmis-vastuvõtu akt (andja, vastuvõtja, omanik).

8.2.7. Teenuse lõppedes, uude keskkonda andmete migratsiooni ettevalmistamine ja läbiviimisel abi osutamine (Täitja pädevuse ulatuses) on majutusteenuse osa ja ei ole eraldi tasustatav.

8.3. Nõuded andmete hoidmisele 8.3.1. Kõik infosüsteemis töödeldavad andmed (andmebaasis ja rakendusserverites) peavad

paiknema keskses andmesalvestusmassiivis, mille andmemaht on lihtsasti juurde tellitav. Andmesalvestusmassiiv peab võimaldama andmete kloonimist töökeskkonnast töökeskkonna-eelsesse ja testkeskkonda. Andmesalvestusmassiivi mis tahes komponendi rike ei tohi põhjustada andmekadu.

8.3.2. Täitja peab maandama andmesalvestusmassiivi riknemise riski, mis võib Tellijale tähendada ulatuslikku teenusekatkestust. Täitja kirjeldab pakkumuses, kuidas ja mis vahenditega (sh SAN seadmed ja andmesalvestusmassiivid) on tagatud mainitud riskide maandamine.

8.4. X-tee turvaserverid 8.4.1. SKAIS1 infosüsteemis on kasutusel x-tee versioon 6 raamistik. 8.4.2. X-tee turvaserverite töökeskkonna, toodangueelse keskkonna ja testkeskkonna

tagab Tellija (asuvad Tellija juures). 8.4.3. Infosüsteemi osade ühtlustamise ja edasiarenduste raames peab Täitjal olema

valmidus x-tee turvaserveri majutus- ja haldusteenuse osutamiseks sarnaselt SKAIS2 alaminfosüsteemile.

8.5. Muudatuste haldus 8.5.1. Arendusmuudatuste paigalduse õigus on ainult Täitjal, kui ei lepita kokku teisiti. 8.5.2. Arendusmuudatused valmistab ette Arendaja ja edastab paketeeritult koos

paigaldusjuhendiga paigaldamiseks toodangu- ja toodangueelsesse keskkonda. Paigalduspakettide, juhendite jm vajaliku informatsiooni edastamiseks ja paigaldustega seotud tegevuste dokumenteerimiseks, kasutatakse Tellija tööde/projektide juhtimise keskkonda Jira.

8.5.3. Teenusetäitja paigaldab arendusmuudatusi lepingu raames vastavalt teenuse passile. 8.5.4. Toodangukeskkonda ja toodangueelsesse keskkonda tehakse üldjuhul kuni 4

arendusmuudatuse tarnet ja 4 veaparandustarnet kuus. Testkeskkonda tehakse üldjuhul kuni 12 arendusmuudatuse tarnet ja 12 veaparandustarnet kuus. Arendusmuudatusi töökeskkonda viiakse sisse väljaspool aktiivset tööaega.

8.5.5. Teenusetäitja peab vastavalt tellimusele käivitama parandusskripte vigade tuvastamiseks ja parandamiseks.

8.5.6. Arendusmuudatuste paigalduse aja kooskõlastab Täitja Tellijaga. 8.5.7. Täitja poolt arendusmuudatuse paigalduse ebaõnnestumisel vastutab Täitja süsteemi

taastamise (rollback) eest. 8.5.8. Täitja uuendab toodangueelse ja testkeskkonna andmeid toodangukeskkonna

andmetega Tellija tellimusel kui tarnejuhend seda ette näeb, kuid mitte rohkem kui punktis 10.5.4 kirjeldatud tarnete arv.

8.5.9. Teenusetäitja tagab Tellija tellimisel arenduspartneritele ligipääsu test- ja toodangueelsele keskkonnale (andmebaasile, rakendusserverile) 2 tööpäeva jooksul.

8.5.10. Teenusetäitja tagab Tellija tellimisel arenduspartneritele ligipääsu sulgemise test- ja toodangueelsele keskkonnale esimesel võimalusel, kuid mitte hiljem kui 2 tööpäeva jooksul.

8.5.11. Täitja peab kindlustama Tellija tellimisel (andme)halduritele / rakenduse administraatoritele lugemisõigustes (read only) ligipääsud kõikide SKAIS2 keskkondade serverite operatsioonisüsteemi konfiguratsioonifailidele ja andmebaasidele.

8.6. Varundamine ja teenuse taastamine 8.6.1. Täitja teeb majutuskeskkonnas olevatest süsteemidest regulaarselt varukoopiaid

selliselt, et oleks tagatud teenuse passis sätestatud tingimuste täitmine. Täitja peab pakkumises kirjeldama, et milliste vahendite ja meetoditega tehakse varukoopiaid.

8.6.2. Varukoopiaid tehakse rakendusi seiskamata st, et Tellija infosüsteemide käideldavus ei ole varukoopiate tegemise ajal mõjutatud. Varundust teostatakse väljaspool infosüsteemi tööaega.

8.6.3. Varukoopiad tuleb salvestada töökeskkonnast eraldi asuvatele andmekandjatele, mis asuvad erinevas füüsilises lokatsioonis. Varukoopiad ja nende allika vaheline andmevahetus peab olema krüpteeritud.

8.6.4. Täitja on kohustatud hoidma töökeskkonna varundatud andmeid järgnevalt: 8.6.4.1. Vähemalt kahe viimase kuukoopia. 8.6.4.2. Vähemalt neli viimast nädalakoopiat. 8.6.4.3. Vähemalt viis viimast tööpäevakoopiat.

8.6.5. Kuukoopiad on planeeritud kopeerida täiendavalt andmesaatkonda. Ajakava ning täpne tehniline lahendus töötatakse välja ja realiseeritakse koos eduka Täitjaga töö käigus 2020/21.aastal.

8.6.6. Andmekadu põhjustavat intsidenti käsitletakse kui erakorralist intsidenti. Erakorralise intsidendi korral on lubatud teenuse järjestikune seisak kuni 4 tundi ja summaarne seisak kuni 4 tundi nädalas ja kuni 6 tundi kalendrikuus. Pärast intsidendi lahendamist ja/või andmete taastamist esitab Täitja Tellijale detailse raporti, kus toob välja intsidendi põhjuse, mis põhjustas andmekadu ning meetmed selliste juhtumite vältimiseks või esinemise tõenäosuse vähendamiseks tulevikus.

8.6.7. Täitja töötab pärast iga keskkonna käivitamist ühe kuu jooksul välja vastava keskkonna taasteplaani ja esitab selle Tellijale ülevaatamiseks ja kinnitamiseks. Taasteplaan peab sisaldama tegevuskava ja süsteemi üldist arhitektuuri kirjeldust visuaalsel kujul. Olulised infrastruktuuri komponendid (serverid, võrguseadmed jne) peavad olema kirjalikult lahti seletatud.

8.6.8. Täitja testib taasteplaani ajakohasust, kui toimub muudatus Tellija infosüsteemiga seotud infrastruktuuris, kuid mitte harvemini kui üks kord aastas. Täitja kooskõlastab Tellijaga testi läbiviimise aja ning esitab Tellijale pärast testi läbiviimist raporti, kus märgib ära taasteplaani vastavuse tegelikule olukorrale ja plaanist leitud puudused. Puudused tuleb kõrvaldada Tellijaga kokkuleppel mõistliku aja jooksul ning seejärel korraldada uus taasteplaani test.

8.7. Monitooring 8.7.1. Täitja tagab tsentraliseeritud tehnilise toe teenuse, mis on avatud 24 tundi ööpäevas ja

seitse päeva nädalas, mille kaudu sooritatakse mitmesuguseid süsteemiga seotud järelevalve, muudatuste ja veahalduse menetlustoiminguid.

8.7.2. Tehnilise toe teenuseid osutatakse osana majutusteenustest, kus kõik süsteemihoiatused saadetakse tsentraliseeritud 24 tundi toimivale tehnilisele toele (sh võrgu, serveri ja rakenduse hoiatused).

8.7.3. Kõik keskkonnad peavad olema Täitja poolt monitooritud kogu lepinguperioodi vältel. 8.7.4. Täitja võimaldab Tellijale ja Tellija poolt nimetatud arendajale juurdepääsu

monitooringuinfole või edastab monitooringuteated Tellija poolt etteantud meiliaadressile.

8.7.5. Täitja installeerib vajadusel või Tellija palvel serveritesse täiendavad monitooringuagendid, mis koguvad infot serverite ja rakenduste seisundi kohta. Tellijal on kasutusel monitooringu süsteem Prometheus ja Grafana.

8.7.6. Täitja monitoorib serverites asuvate infosüsteemide tööd vähemalt järgmiste komponentide osas:

8.7.6.1. Andmesideühenduse olemasolu Tellija serverite ja infosüsteemide vahel. 8.7.6.2. Serverite riistvaraliste komponentide töökorras olek. 8.7.6.3. Serverite protsessorite ja mälukasutus. 8.7.6.4. Kõvaketaste täituvus. 8.7.6.5. Süsteemi load (UNIX süsteemide puhul). 8.7.6.6. Andmebaasisüsteemi töökorras olek. 8.7.6.7. Andmebaasile eraldatud ressursside olemasolu. 8.7.6.8. Varukoopiate tegemise õnnestumine. 8.7.6.9. Monitooringusüsteemi töökorras olek.

8.7.7. SKAIS1 infosüsteemi rakenduste monitooring 8.7.7.1. Täitja poolset SKAIS1 rakenduse monitooringut ei nõuta. Täitjal peab olema

valmisolek integreerida oma keskkonda Tellija poolt kasututavad rakenduse monitooringu vahendid (agendid vms).

8.7.8. Teenuse tehniline tugi 8.7.8.1. Täitja peab tagama kasutajatoe (ühtne kontaktpunkt, telefoni number, e-

mail ja/või avalik portaal) vastavalt Teenuse passis toodud nõuetele. 8.7.8.2. Täitja peab teavitama Tellijat kriitilistest ja keskmise taseme vigadest

koheselt ja asuma teenuse nõutud tingimustele vastavust taastama. 8.7.8.3. Kui tõrget ei ole võimalik teenuse passis nõutud aja jooksul lahendada, peab

Täitja esitama põhjendused ja lahendusettepanekud. 8.7.8.4. Kriitilise taseme tõrkeks loetakse olukorda, kus SKAIS1 toodangukeskkonna

tervikuna või oluliste komponentide, s.h andmevahetused teiste infosüsteemidega, kasutamine ei ole võimalik.

8.7.8.5. Keskmise taseme tõrkeks loetakse olukorda, kus SKAIS1 toodangukeskkonna kasutamine on oluliselt häiritud.

8.7.8.6. Madala taseme tõrkeks loetakse olukorda, kus SKAIS1 toodangukeskkonna kasutamine on võimalik, kuid on häiritud.

8.7.9. Aruandlus ja infovahetus 8.7.9.1. Täitja esitab majutusteenuse osutamise kohta igakuiselt ülevaate eelmise

kuu kohta, mis sisaldab vähemalt järgmist informatsiooni: 8.7.9.1.1. Süsteemi komponentide käideldavus vastavalt teenuste passi

nõuetele. 8.7.9.1.2. Perioodi vältel toimunud intsidendid koos algus- ja lõpuajaga,

juurpõhjusega (kui on selgunud) ning kirjeldusega, kuidas neid edaspidi vältida.

8.7.9.1.3. Perioodi vältel tehtud plaanilised tööd. 8.7.9.1.4. Muudatuste logi. 8.7.9.1.5. Tellija poolt perioodi jooksul esitatud pöördumiste staatus, mis

sisaldab ka lahendamata pöördumisi eelmistest perioodidest. 8.7.9.1.6. Täitja poolsed ettepanekud infosüsteemi ja majutuse parendamiseks

ning teostamiskava. 8.7.9.2. Aruandlus peab olema Tellija kontaktisikutele kättesaadavaks tehtud veebi

kaudu või e-kirja teel. 8.7.9.3. Täitja peab võimaldama Tellijal tellida tellimustööna täiendava tasu eest

ühekordseid raporteid nt andmebaasi detailseid koormusraporteid. 8.7.9.4. Täitja ja Tellija vaheline töökeel on eesti keel.

9. Lokatsioonide näitlik loogiline arhitektuur

II. SKAIS2 arhitektuuridokument

1. Sissejuhatus

1.1. Antud dokument kirjeldab juba valminud SKAIS2 infosüsteemi arhitektuuri, sisaldades antud süsteemi komponentide kirjeldust, omavahelist suhtlemist ja suhestumist, paigaldusvaadet ning kirjeldust loodava süsteemi ning teda ümbritsevate keskkondade vahel.

2. Süsteemi taust

2.1. Sotsiaalkindlustusameti infosüsteem (SKAIS2) on riigi infosüsteemi kuuluv andmekogu.

Aastaks 2018 oli välja arendatud elatisabi ja riigile üle läinud elatisnõuete sissenõudmise;

puude raskusastme ja puudest tulenevate lisakulude ning püsiva töövõimetuse tuvastamise

funktsionaalsus.

2.2. Aastatel 2018–2020 lisandusid SKAIS2 infosüsteemi Perehüvitiste pakkumuste

sündmuspõhine teenus, Tehniliste abivahendite taotlemise ja soodustingimustel

eraldamise infosüsteem, Isa täiendava vanemahüvitise puhkuse planeerimise võimalus,

Vanemahüvitiste- ning Kogumispensioni täiendavate sissemaksete funktsionaalsus.

2.3. Aastatel 2021-2023 lisandus Pensioniõigusliku staaži andmete kogumise teenus ja uuenesid

Digitembeldamise -, Dokumentide haldamise -, Rahvastikuregistriga liidestumise – ja

Arstliku-ekspertiisi teenused.

2.4. SKAIS2 on liidestatud erinevate üleriigiliste infosüsteemidega. Süsteemis on 1,6 miljoni isiku andmed.

3. Paigaldusvaade

3.1. Järgnevalt kirjeldatakse süsteemi komponentide paigaldust ja omavahelist suhtlust.

Infosüsteem on laias laastus jagatud kaheks:

3.1.1. sisevõrgus paiknevad süsteemi osad 3.1.2. välisvõrgust ligipääsetavad süsteemi osad

3.2. Välisvõrgus asub Sotsiaalkindlustusameti iseteeninduse rakendus, mis suhtleb sisevõrgus olevate komponentidega üle standardse HTTPS protokolli. Ligipääs sisevõrgus olevatele komponentidele on määratud välisvõrgus asuva serveri(te) IP aadressi(de) näol.

3.3. Rakendusserveritele (Apache Tomcat1) paigaldatud komponendid (Ametniku portaal) on paljundatavad (hetkel kasutatav sessiooni sticky-session asendub tulevikus Redise2 andmebaasil põhineva sessiooni haldusega). Süsteem võimaldab lisada N arv lisa servereid, koormust juhib rakendusserverite ette paigaldatud koormusjaotur Apache3 mod_proxy4.

3.4. Uuemad (pärast 2018 arendatud) komponendid on arendatud mikroteenuste5 põhimõtteid jälgides ning väldivad kasutaja sessiooni oleku hoidmist rakendusserveris. Valitud lahendus võimaldab rakenduse komponente paljundada ja lõppkasutajale märkamatult (katkestuste vabalt) vahetada.

3.5. Andmebaasi ühendusi hallatakse rakendusesisese Connection Pooli abil. Infosüsteem töötab läbivalt UTF-8 kodeeringus.

3.6. Süsteemi aluseks olev andmebaas on paigaldatud kahte erinevasse serveriruumi (active/passive site), kus ainult üks on aktiivses olekus.

1 Apache Tomcat — http://tomcat.apache.org/ 2 Redis — https://redis.io/ 3 Apache HTTP Server — https://httpd.apache.org/ 4 mod_proxy — https://httpd.apache.org/docs/2.4/mod/mod_proxy.html 5 Mikroteenuste arhitektuur — https://microservices.io/

3.7. Java rakendused on klasterdatud 2 aktiivse õlga (node) vahel, mis on paigutatud erinevatesse serveriruumidesse (st. 1 õlg serveriruumi peale).

3.8. SKAIS2 integreerub erinevate väliste infosüsteemidega: 3.8.1. infovahetus teiste riigi andmekogudega tuimub üle X-tee6 kasutades HTTP(S) REST ja

SOAP 7 protokolli. 3.8.2. Infovahetus SKAIS1-ga toimub üle andmebaasiühenduste (JDBC ja DBLink8) 3.8.3. Euroopa Liidu ühtse sotsiaalkindlustuse infovahetus (EESSI9) käib läbi

Sotsiaalkindlustusameti RINA rakenduse kasutades HTTP protokolli, vahetades REST sõnumeid.

3.8.4. Väljamakseid teostatakse kasutades Eesti pankade poolt pakutavaid teenuseid.

3.8.5. Ametniku portaal – Sotsiaalkindlustusameti ametnikele mõeldud veebirakendus.

6 X-tee andmevahetuse platform — https://www.x-tee.ee/home 7 SOAP protokoll — https://www.w3.org/TR/soap/ 8 Oracle Database Links: https://docs.oracle.com/cd/E18283_01/server.112/e17120/ds_concepts002.htm 9 Electronic Exchange of Social Security Information — https://ec.europa.eu/social/main.jsp?catId=869&langId=en

3.8.6. Komposiit - ajutine veebirakendus, mis pakendab endas erinevate valdkondade

mikroteenuseid (failihaldus, finants (arvestus), iseteenindus, isik, kogumispension,

maksude deklareerimine, otsus/hüvitis, pakkumus, perehüvitis, parameeter,

sotsiaalmaksu hüvitamine, teavitused, tööülesanded, universaalmenetlus,

vanemahüvitis, x-tee väljuvad päringud). Ajutine lahendus kuni toodangus võetakse

kasutusele Kubernetes10.

3.8.7. RINA Facade – EESSI RINA liidestus. Integratsiooni komponent. Vahendab EESSI

RINA ja SKAIS2 vahelist suhtlust üleeuroopaliste sotsiaalkindlustuse juhtumite

menetlemiseks SKAIS2 kaudu. Eraldi käivitatav Java (Spring Boot11) rakendus.

3.8.8. Abivahendid – Tehniliste abivahendite ärimoodul. Haldab riigi poolt toetatud,

soodustingimustel teostatud, abivahendite tehingute registreerimisi ja neist

tulenevaid äriprotsesse. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.9. Arestid – Kolmandate osapoolte (kohtutäiturid) poolt Sotsiaalkindlustusametile

edastatud arestiaktide alusel kinnipidamiste teostamine ja haldus. Eraldi käivitatav

Java (Spring Boot) rakendus.

3.8.10. Elatisabi – Elatisabi teenuse ärimoodul. Haldab riigi poolt pakutavaid Elatisabi

teenuseid ja neist tulenevaid äriprotsesse. Eraldi käivitatav Java (Spring Boot)

rakendus.

3.8.11. Kindlustuslepingud – Kindlustusandjate poolt riigile üleantud pensioni II samba

lepingute haldusmoodul. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.12. Kliendipöördumised – Kliendipöördumiste ja -suhtluse ärimoodul.

Kliendipöördumiste ärimoodulis hallatakse kogu kliendiga toimuvat suhtlust, kus

suhtluse algatajaks võib olla nii klient kui ka Sotsiaalkindlustusameti töötaja. Eraldi

käivitatav Java (Spring Boot) rakendus.

3.8.13. RFK klassifikaator – Rahvusvahelise funktsioneerimisvõime, vaeguste ja tervise

klassifikatsiooni (ICF12) haldusmoodul. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.14. Ekspertarsti hinnang – Sotsiaaltoetuste aluseks olev, isiku puude - ja toimetuleku

hindamise moodul. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.15. Finants facade – SKAIS1s määratud pensionite, toetuste ja hüvitiste

finantsarvestuse teostamise integratsioonimoodul. Eraldi käivitatav Java (Spring Boot)

rakendus.

3.8.16. Rahvastikuregistri andmete töötlemine – Rahvastikuregistriga liidestumise ja

rahvastikuregistrist saadud andmete töölemise teenus. Vastutab rahvastrikuregistriga

liidestuste eest (sh. Isikuandmete muudatused/ Isiku detailandmed/ Isiku viibimiskoht/

Isiku dokumendid) . Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.17. Dokumentide hoidla – SKAIS2 põhiteenus isikuga seotud dokumentide hoidmiseks.

Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.18. Pensioniõiguslik staaž – Pensioni määramiseks alusandmete, Pensioniõiguslike

staažide, kogumise ja haldamise moodul. Eraldi käivitatav Java (Spring Boot) rakendus.

10 Kubernetes konteinerite orkestratsioon — https://kubernetes.io/ 11 Spring Boot Java rakenduste raamistik — https://spring.io/projects/spring-boot 12 ICF (International Classification of Functioning, Disability and Health) - https://www.who.int/standards/classifications/international-classification-of-functioning-disability-and-health

3.8.19. Arstlik-ekspertiis küsimustik – Arstliku-ekpertiisi taotluse juures kasutatav

küsimustiku haldamise moodul. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.20. Arstlik-ekspertiis menetlus – Arstliku-ekpertiisi menetlemise moodul (hetkel

kasutatakse puudeotsuste edastamiseks STAR-i süsteemi). Eraldi käivitatav Java (Spring

Boot) rakendus.

3.8.21. Arstlik-ekspertiis taotlus – Arstliku-ekspertiisi taotlemise moodul. Antud mooduli

kaudu saavad kodanikud esitada iseteenindusest puude hindamise ja sotsiaaltoetuste

taotlusi. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.22. Protsessimootor - kasutatakse virtuaalmasinas eraldiseisva protsessina (jar).

Teostab süsteemis defineeritud ja järjekorda seatud taustaprotsesside jooksutamist.

Jõudluse tõstmiseks on võimalik paigaldada mitu protsessimootorit.

3.8.23. Dokumendi generaator - vahend (Oracle BI Publisher13) menetlusprotsesside käigus

koostatavate dokumentide koostamiseks ja automaatseks genereerimiseks.

Liidestatud teiste süsteemidega kasutades Oracle BI Publisher Java Integration API't. BI

Publisheri kasutus on tasapisi asendumas ärimoodulite endi sees genereeritud

dokumentidega.

3.8.24. X-tee turvaserver – X-tee liidestus. Installeeritud vastavalt turvaserveri

installeerimisjuhendile: http://x-road.ee/docs/est/turvaserveri_kasutusjuhend.pdf.

3.8.25. X-tee andmejälgija – X-tee andmejälgija liidestus. Installeeritud vastavalt

andmejälgija paigaldamise juhendile: https://github.com/e-

gov/AJ/blob/master/doc/Rakendusjuhend.md#tarkvara-paigaldamine

3.8.26. HSM - (hardware security module) riistvaraline turvamoodul PKI infrastruktuuris

turvaliselt saladuste krüpteerimiseks ja signatuuride kinnitamiseks.

3.8.27. X-tee teenusetäitja - Installeeritud eraldiseisvana virtuaalmasinasse (Apache +

Tomcat). Vahendab SKAIS2 poolt pakutavaid x-tee teenuseid välistele süsteemidele,

mis on loodud kasutades SOAP protokolli. Liidestus X-Tee turvaserveriga, pakub

andmeid.

3.8.28. X-road teenusetäitja - Vahendab SKAIS2 poolt pakutavaid x-tee teenuseid välistele

süsteemidele, mis on loodud kasutades REST protokolli. Liidestus X-Tee

turvaserveriga, pakub andmeid. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.29. Abivahendite X-tee teenusetäitja – Installeeritud eraldiseisvana virtuaalmasinasse

Java (Spring Boot) rakendusena. Vahendab SKAIS2 pakutavaid abivahendite X-tee

teenuste otspunkte. Liidestus X-tee turvaserveriga, pakub andmeid.

3.8.30. "Tuum" Andmebaas – Oracle Database 19c Enterprise Edition, hoitakse ja

töödeldakse kogu SKAIS2 andmestikku. Kasutusel 36 schemat (skais_assignment,

skais_benefit, skais_client_inquiry, skais_dashboard, skais_disability_application,

skais_disability_proceeding, skais_disability_question, skais_doctor_assessment,

skais_document_management, skais_finance, skais_fin_facade, skais_funded_pension,

skais_funded_pension_payments, skais_isik, skais_maintenance_allowance,

skais_notification, skais_pakkumus, skais_parental_benefit, skais_pension_seniority,

skais_perehyvitis, skais_population_reg_proc, skais_proceeding, skais_rfk_classifier,

skais_rinafacade, skais_signing, skais_social_tax_benefit, skais_system,

13 Oracle Business Intelligence Publisher — https://www.oracle.com/middleware/technologies/bi-publisher.html

skais_tax_declaration, skais_technicalaid, skais_technicalaidxroad, skais_withholdings,

skais_xroad, skais_xroad_provider, skais2, skais2sys, skais2valine).

3.8.31. Failihoidla – Oracle Database 19c Enterprise Editon hoidmaks äriprotsesside poolt

loodud ja süsteemi kasutajate poolt üleslaetud dokumente.

3.8.32. Dokumentide arhivaator – Daemon komponent (jar) operatiivbaasi salvestatud

dokumentide liigutamiseks arhiivi (failihoidla andmebaasi).

3.8.33. Digitempli teenus – Äriteenuste poolt loodud otsuste ja maskefailide allkirjastamise

(digitembeldamise) teenus. Allkirjastatud failid saavad asutuse digitempli ASiCe

formaadis. Eraldi käivitatav Java (Spring Boot) rakendus.

3.8.34. ERP - Oracle E-Business Suite14 paigaldatuna eraldi serverile. Haldab/töötleb SKAIS2

raamatupidamisinfot (maksed panka või muudesse maksekanalitesse (kojukanne),

pangast tagasiside jne). ERPi taga on erinevad liidestused pankadega. SKAIS2

integratsioon ERPiga on tehtud läbi vahetabelite. Skais2 lisab read tabelitesse, kus

ERP need üles korjab. Pärast tagasisidet pangast kirjutab ERP read tabelisse, kus

SKAIS2 need jälle üles korjab ja oma ärilistesse tabelitesse laiali salvestab.

3.8.35. Swedbank GW – ERP Liidestus Swedbank’i maksete liidesega. Vahendab

väljamaksete infot ERP ja Swedbank’i vahel.

14 Oracle E-Business Suite — https://www.oracle.com/applications/ebusiness/

4. Rajadokument

4.1. "Tuum" Andmebaas

4.1.1. Oracle Database 19c Enterprise Edition. 4.1.2. Tüüp: Andmebaas 4.1.3. Kasutatud protokoll: JDBC 4.1.4. Käideldavus: kõrgkäideldav active-passive klaster kahel õlal.

4.2. Iseteeninduse portaal (brauseri rakendus)

4.2.1. Sotsiaalkindlustusameti klientidele mõeldud veebirakendus. 4.2.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.2.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST). 4.2.4. Käideldavus: Brauseris töötav kasutajaliides.

4.3. Ametniku portaal

4.3.1. Sotsiaalkindlustusameti ametnikele mõeldud veebirakendus. 4.3.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.3.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST) 4.3.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.4. Elatisabi

4.4.1. Elatisabi teenuse ärimoodul 4.4.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.4.3. Kasutatud protokoll: HTTP(S) REST, Angular. 4.4.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.5. Kliendipöördumised

4.5.1. Kliendipöördumiste ja -suhtluse ärimoodul 4.5.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.5.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST) 4.5.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.6. Kindlustuslepingud

4.6.1. Kindlustusandjate poolt riigile üleantud pensioni II samba lepingute haldusmoodul 4.6.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.6.3.Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST) 4.6.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.7. Arestid

4.7.1. Arestide (kinnipidamiste) teostamise ja halduse ärimoodul 4.7.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.7.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST) 4.7.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.8. RFK klassifikaator

4.8.1. Rahvusvahelise funktsioneerimisvõime, vaeguste ja tervise klassifikatsiooni haldusmoodul.

4.8.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.8.3. Kasutatud protokoll: AMQP, HTTP(S) (REST) 4.8.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.9. Ekspertarsti hinnang

4.9.1. Isiku puude - ja toimetuleku hindamise ärimoodul 4.9.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.9.3.Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST) 4.9.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.10. Finants facade

4.10.1. SKAIS1s määratud pensionite, toetuste ja hüvitiste finantsarvestuse teostamise integratsioonimoodul.

4.10.2. Tüüp: sisemisi teenuseid pakkuv veebirakendus.

4.10.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST) 4.10.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.11. Komposiit

4.11.1. Ajutine mikroteenuse komponentide konteiner (Apache Tomcat) 4.11.2. Tüüp: Avalike ja sisevõrgu teenuseid pakkuvate rakenduste konteiner. 4.11.3. Kasutatud protokoll: HTTP(S) (REST)

4.12. SiGa/SiVa proxy

4.12.1. TEHIKu sisene proxy teenus, mis vahendab RIA poolt pakutud SiGa/SiVa teenust. 4.12.2. Tüüp: sisemisi teenuseid pakkuv veebirakendus. 4.12.3. Kasutatud protokoll: HTTP(S) (REST) 4.12.4. Käideldavus: k8s klastrisse ja koormusjaoturi taha paigaldatud mikroteenus.

4.13. Protsessimootor

4.13.1. Kasutuses eraldiseisva protsessina virtuaalmasinas täitmaks süsteemis defineeritud ja järjekorda seatud taustaprotsesse või üle Oracle AQ saabunud sõnumeid. Töötab eraldiseisva(te) protsessi(de)na Daemon protsesside jooksutamiseks.

4.13.2. Tüüp: sünkroonne ja asünkroonne teenus; süsteemne taustaprotsess. 4.13.3. Kasutatud protokoll: AMQP, HTTP(S) (REST), JDBC

4.14. Digitempli teenus

4.14.1. Digitembeldamise teenus, digitembeldab etteantud faile, lisab failid failihoidlasse. Sisemiselt kasutab digitembeldamise APIt. Signeerimiseks kasutab majutuskohas olevat võrgu HSM seadet.

4.14.2. Tüüp: sisemisi teenuseid pakkuv veebirakendus. 4.14.3. Kasutatud protokoll: AMQP, JDBC 4.14.4. Käideldavus: klastrisse paigaldatud mikroteenus

4.15. Failihoidla

4.15.1. Süsteem (Andmebaas + Java API) hoidmaks dokumendi generaatori poolt loodud, süsteemi kasutajate poolt üleslaetud ja protsessi mootori poolt loodud dokumente. Paigaldatud eraldiseisvasse virtuaalmasinasse.

4.15.2. Tüüp: Teenus (API), Andmebaas. 4.15.3. Kasutatud protokoll: JDBC; HTTPS

4.16. Rahvastikuregistri andmete töötlemine

4.16.1. Rahvastikuregistri andmete pärimise ja töötlemise teenus 4.16.2. Tüüp: sisemisi teenuseid pakkuv veebirakendus. 4.16.3. Kasutatud protokoll: AMQP, HTTP(S) (REST), JDBC 4.16.4. Käideldavus: klastrisse paigaldatud mikroteenus

4.17. Dokumentide hoidla

4.17.1. Isikuga seotud dokumentide haldamise ärimoodul 4.17.2. Tüüp: avalikke ja sisemisi teenuseid pakkuv veebirakendus. 4.17.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST), JDBC 4.17.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.18. Pensioniõiguslik staaž

4.18.1. Pensioniõiguslike staažide, kogumise ja haldamise ärimoodul 4.18.2. Tüüp: avalikke ja sisemisi teenuseid pakkuv veebirakendus. 4.18.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST), JDBC 4.18.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.19. Arstlik-ekspertiis küsimustik

4.19.1. Arstliku-ekpertiisi taotluse juures kasutatav küsimustiku haldamise moodul 4.19.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.19.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST),JDBC 4.19.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.20. Arstlik-ekspertiis menetlus

4.20.1. Arstliku-ekspertiisi menetlemise ärimoodul 4.20.2. Tüüp: sisemisi teenuseid pakkuv veebirakendus. 4.20.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST), JDBC 4.20.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.21. Arstlik-ekspertiis taotlus

4.21.1. Puude tuvastamise ja sotsiaaltoetuste taotlemise ärimoodul 4.21.2. Tüüp: avalikke teenuseid pakkuv veebirakendus. 4.21.3. Kasutatud protokoll: AJP, AMQP, HTTP(S) (REST), JDBC 4.21.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.22. Dokumendi generaator

4.22.1. Vahend menetlusprotsesside käigus koostatavate dokumentide genereerimiseks. Liidestatakse teiste süsteemidega kasutades Oracle BI Publisher Java Integration API'sid.

4.22.2. Tüüp: sünkroonsed teenused API tarbijatele, veebileht administreerimiseks. 4.22.3. Vastaspool: liidese tarbijaks on Ametniku portaal ja protsessimootor. 4.22.4. Kasutatud protokoll: Oracle BI Publisheri põhine, ühenduse hoidmiseks kasutatakse

Oracle poolt pakutud APIt. Port millelt ühendus luuakse, konfigureeritav süsteemis (by default 7001).

4.22.5. Lisa: Rakendus vajab oma repositooriumi hoidmiseks andmebaasi. 4.23. ERP

4.23.1. Oracle E-Business Suite paigaldatuna eraldi serverile. Haldab/töötleb SKAIS2 raamatupidamisinfot—maksed panka või muudesse maksekanalitesse (kojukanne), pangast tagasiside jne. SKAIS2 integratsioon ERPiga on teostatud läbi vahetabelite. SKAIS2 lisab read tabelitesse, kus ERP need üles korjab. Pärast tagasisidet pangast kirjutab ERP read tabelisse, kus SKAIS2 need üles korjab ja oma ärilistesse tabelitesse laiali salvestab.

4.24. Turvaserver

4.24.1. X-tee turvaserver, vajalik X-tee kaudu andmete vahetamiseks. 4.24.2. Kasutatud protokollid: HTTP(S) REST ja SOAP.

4.25. Dokumentide arhiveerija

4.25.1. Daemon protsess, eesmärgiga arhiveerida operatiivbaasi salvestatud dokumente failihoidlasse.

4.25.2. Tüüp: Deemon protsess. 4.25.3. Kasutatud protokoll: JDBC.

4.26. Pank

4.26.1. Väljamaksete edastamine panka. 4.26.2. Tüüp: asünkroonne gateway. 4.26.3. Kasutatud protokoll: SOAP.

4.27. X-tee

4.27.1. Suhtlus erinevate andmekogudega. 4.27.2. SKAIS2 poolt pakutavad teenused:

Teenus Selgitus

EAFmakseteatised Teenus võtab kohtutäituritelt vastu täitemenetluseaegse

elatisabi maksekorraldused.

EAFmakseraport Teenus väljastab kohtutäituritele täitemenetluseaegse

elatisabi maksekorralduste staatused. Info selle kohta, kas

Sotsiaalkindlustusameti poolt on maksekorralduse põhjal

väljamakse teinud või tagastab veateate, miks

maksekorraldust ei ole võimalik täita.

Teenus Selgitus

TKToovoimPuueHyvitised Teenus väljastab Töötukassale päritava isiku kohta info,

milliseid hüvitisi ja töövõimetusi on määratud isikule

Sotsiaalkindlustusametis. Lisaks väljastatakse ka rahaliste

väljamaksete, kinnipidamiste ja tulumaksu info.

TKToovoimPuueHyvitisedMassTeenus Teenus võtab vastu Töötukassast isikukoodide loetelu, kelle

kohta Töötukassa soovib hüvitiste infot.

TKToovoimPuueHyvitisedMassTeenusVastus Teenus väljastab Töötukassale päritavate isikute kohta info,

milliseid hüvitisi ja töövõimetusi on määratud isikule

Sotsiaalkindlustusametis

TVHTaotlusYksUks Teenus võtab vastu Töötukassast puude määramise taotluse

andmed.

calculateContributionV2 Arvutab etteantud abivahendite müügi tehingu ridadele riigi

poolt teenuseosutajale hüvitatavate osamaksete suurused.

calculateIsoLimitParametersV2 Arvutab isikule müüdava abivahendi ISO koodi alusel talle

määratud abivahendi soodustuse kasutamise piirmäärad.

cancelTransactionRowV2 Tühistab eelnevalt registreeritud abivahendi müügi- või

renditehingu.

changeContribution Teenus abivahendite teenuseosutajatele osamaksete

muutmiseks

checkJustificationV2 Kontrollib isiku õigustatust soodustingimusel abivahendi

soetamiseks.

correctTransaction Teenus abivahendite teenuseosutajatele tehingute

korrigeerimiseks.

courierDelivery Teenus väljastab kojukande teenuseosutajale rahaliste

hüvitiste väljamaksete info.

courierDeliveryAnnulation Teenus väljastab kojukande teenuseosutajale tühistatud

rahaliste hüvitiste väljamaksete info.

courierDeliveryReply Teenus võtab vastu kojukande teenuseosutajalt teostatud

väljamaksete info - kas õnnestus raha kliendile viia või mitte.

createTransactionV2 Registreerib uue abivahendi müügi- või renditehingu.

endRental Lõpetab kehtiva abivahendi rendi perioodi

findUsage Teenus väljastab Eesti.ee jaoks SKAIS2 poolt pakutavate

isikustatud Xtee teenuste kasutamise infot.

incomeTaxExemptionV1 Teenus pensionikeskusele isiku tulumaksuarvestuse vaba jääk

isikutePuuded Tagastab Kaitseressursside ametile isikute puude info

nonResidencePersons Teenus väljastab etteantud perioodis

Sotsiaalkindlustusametile teavitatud välisriikide

maksuresidentsuse andmed (sh. riigi, perioodi, tõendi staatuse

ja registreerimise aja kohta)

providerValidity Valideerib et vastaval teenuseosutajal on õigus teostada

soodustingimustel abivahendi müüki.

requestTransactionEvents Teenus abivahendite teenuseosutajatele tehtud tehingute

sündmuste pärimiseks.

requestTransactions Teenus abivahendite teenuseosutajatele tehtud tehingute

pärimiseks

star1Tulud Teenus väljastab kohalikele omavalitsustele päritava isiku

kohta info, milliseid hüvitisi on Sotsiaalkindlustusameti poolt

Teenus Selgitus

isikule määratud. Millised on olnud hüvitiste väljamaksed ja

kinnipidamised.

starPuue2 Teenus väljastab kohalikele omavalitsustele, milliseid puuded

on isikule määratud.

taituri_vmaksed Teenus väljastab kohtutäituritele Sotsiaalkindlustusameti

poolt isikutele teostatud väljamaksete info.

tlvIsikuPuudeInfo Teenus väljastab Tallinna linnavalitsusele päritava isiku kohta

info, mis liiki puue on isikule määratud.

4.27.3. SKAIS2 poolt tarbitavad teenused:

Andmekogu Teenus Selgitus

arireg lihtandmed_v1 Äriregister - Lihtandmete päring

arireg detailandmed_v3 Äriregister - Ettevõtja detailandmete

päring

at teadaandeLiigid_v2

Ametlikud teadaanded – Teenusega

tagastatakse teadaande liikide

kirjeldused.

at otsiTeadaanne Ametlikud teadaanded – Teenusega

tagastatakse teadaannete info.

digilugu hl7

Terviseinfosüsteem – Teenusega

päritakse Arstliku-eksperiisi taotluse

juurde isiku viimase viie aasta arstivisiite.

ehis sotsList1V2 Eesti hariduse infosüsteem - Õppuri

andmed peretoetuste jaoks

ehis sotsList2 Eesti hariduse infosüsteem - Õppurite

andmed toitjakaotuspensionide jaoks

kirst kindlustatus Haigekassa infosüsteem - Kontrollipäring

isiku kindlustatuse kohta

kirst kindlustusalus Haigekassa infosüsteem – kindlustusaluse

info edastamine haigekassale

kirst tvl_loetelu2 Haigekassa infosüsteem – Päring isiku

töövõimetuslehtede kohta

kpr liitumise_kontrollimine Pensionikeskus – Päring kontrollimaks,

kas isik on liitunud pensioni II sambaga.

kpr maksekohustused

Pensionikeskus – Päring kontrollimaks kas

isik on lõpetanud maksed pensioni II

sambasse.

tsd skaSotsmaks Maksu- ja tolliamet – Päring isiku

sotsiaalmaksu andmete kohta

EMTA PublicNonResidencyInquiry Maksu- ja tolliamet – Päring isiku

residentsuse kohta.

pkr STAR1_TULUD

Pensionikindlustuse register – Päring

kohalikele omavalitsustele makstud

tulude kohta.

pkr taituri_vmaksed Pensionikindlustuse register – Päring

isikule tehtud väljamaksete küsimine.

rr RR456

Rahvastikuregister – Päring isikukoodi

alusel isiku andmete kohta (dokumendid,

suhted ja hooldusõigused)

rr RR67_muutus

Rahvastikuregister – masspäring

isikuandmete muudatuste kohta vastavalt

edastatud ajavahemikule.

rr RRisikuandmeteMuudatused

Rahvastikuregister – uuenenud

masspäring isikuandmete muudatuste

kohta vastavalt edastatud ajavahemikule.

rr RRisikuViibimiskoht

Rahvastikuregister – Päring isiku

viibiiskoha kohta.

star KontrolliToimetulekuToetuseSaamist

STAR - Päring kohalike omavalitsuste

infosüsteemist kontrolimaks isiku

toimetulekutoetuse saamist.

star starPuudeotsusedV1

STAR – proaktiivne teenus, saadetakse

kõik puudeotsused.

Kohalikelomavalitsustel on vajalik teada

isikutele määratud puuded haldusalas

elavate isikute abivajaduse hindamiseks.

tkis EkspertiisArvamusV2

Eesti töötukassa töövõime hindamise

tuvastamise ekspertiisi andmeid välistele

asutustele

tkis TootuArvelolekV2 Töötuna arveloleku andmestik

vanamahüsitise alusandmete jaoks

tkis TVHOtsusV1 Töövõime hindamise tuvastamise otsus

tkis TVHTaotlusNimekiriV1 Töövõime hindamise tuvastamise

taotluste nimekiri

tor TORIK Töötamise informatsiooni küsimine

Töötamise registrist.

tor TOOTREG_AMETNIK Töötamise register - Töötamise andmete

muutmise teenus.

tor uploadMime

Töötamise register - Masspäring

etteantud isikukoodide alusel isikute

töötamise kohta

tor downloadMime Töötamise register - Masspäringu vastus

eelnevalt küsitud isikute töötamise kohta.

4.27.4. Tüüp: sünkroonne

4.27.5. Kasutatud protokoll: SOAP

4.28. X-Road

4.28.1. Suhtlus erinevate andmekogudega.

4.28.2. SKAIS2 poolt pakutavad teenused:

Teenus Selgitus

search-persons-latest-

contacts

Teenusega antakse STAR’ile teada isiku viimased kontaktandmed.

teavitaSynnitahtaegV1 Teenusega võetakse, tervise teenuse osutajatelt (nt. haiglad), vastu

informatsiooni eeldatava(te) sünnitähtaegade kohta.

tyhistaSynnitahtaegV1 Teenusega võetakse, tervise teenuse osutajatelt (nt. Haiglad) vastu

informatsiooni perinataalsurmade kohta.

4.28.3. Tüüp: sünkroonne

4.28.4. Kasutatud protokoll: HTTP(S) REST

5. Süsteemi arhitektuuris kasutatavad tehnoloogiad

5.1. Apache HTTP Server — Versioon: 2.4. Konfiguratsioon ja nõuded: SSL, koormusjaotur

(mod_proxy_balancer), sticky session. Operatsioonisüsteem: RedHat / CentOS / Oracle

Enterprise Linux.

5.2. Apache Tomcat — Versioon: 9.0.x Konfiguratsioon ja nõuded: klasterdamine Tomcat

rakendusserverite tasemel (SimpleTcpCluster). Operatsioonisüsteem: RedHat / CentOS.

5.3. Oracle BI Publisher — Versioon: Oracle Business Intelligence (12.2.x). Konfiguratsioon ja

nõuded: Repositoorium Oracle 19c EE; rakendusserver: Oracle WebLogic (kaasas by default

installatsiooni paketis). Operatsioonisüsteem: Oracle Linux.

5.4. Oracle 19c EE — Versioon: Oracle Database 19c Enterprise Edition 19.13. Konfiguratsioon ja

nõuded: klasterdatud andmebaas. Operatsioonisüsteem: RedHat / CentOS / Oracle

Enterprise Linux.

5.5. Oracle Database Advanced Queuing — kasutatakse erinevate enne 2018 tarnitud

komponentide vahel asünkroonseks suhtluseks.

5.6. Rabbit MQ — Versioon: 3.8.16. Kasutatakse erinevate komponentide vahel asünkroonseks

suhtluseks.

6. Tehnoloogiate maatriks

Rakendus Java SOAP /

REST

Apache

Tomcat

Sõnumi-

vahetus Andmebaas Märkus

Ametniku portaal 11 SOAP +

REST Jah

Oracle AQ

RabbitMQ

Oracle 19c EE

Suhtlus X-teega

kasutab SOAP

liidestust, muu

suhtlus käib REST

ja asünkroonse

sõnumivahetuse

abil.

Komposiit 11 REST Jah RabbitMQ Oracle 19c EE

Abivahendite teenus 11 REST Oracle 19c EE

Arestid 11 REST RabbitMQ Oracle 19c EE

Arstlik-ekspertiis

küsimustik 11 REST RabbitMQ Oracle 19c EE

Arstlik-ekspertiis

menetlus 11 REST RabbitMQ Oracle 19c EE

Arstlik-ekspertiis

taotlus 11 REST RabbitMQ Oracle 19c EE

Dokumendi hoidla 11 REST RabbitMQ Oracle 19c EE

Finants facade 11 REST RabbitMQ Oracle 19c EE

Ekspertarsti hinnang 11 REST RabbitMQ Oracle 19c EE

Elatisabi 11 REST RabbitMQ Oracle 19c EE

Kliendipöördumised 11 REST RabbitMQ Oracle 19c EE

Kindlustuslepingud 11 REST RabbitMQ Oracle 19c EE

Pensioniõiguslik staaž 11 REST RabbitMQ Oracle 19c EE

Rahvastikuregistri

andmete töötlemine 11 REST RabbitMQ Oracle 19c EE

RFK klassifikaator 11 REST RabbitMQ Oracle 19c EE

Digitempli teenus 11

RabbitMQ Oracle 19c EE

Dokumentide

arhivaator 11

Oracle 19c EE

X-tee teenustäitja

(sisenevad) 11 SOAP Jah Oracle 19c EE

Rakendus Java SOAP /

REST

Apache

Tomcat

Sõnumi-

vahetus Andmebaas Märkus

X-road teenustäitja

(sisenevad) 11 REST RabbitMQ Oracle 19c EE

Abivahendite x-tee

teenusetäitja

(sisenevad)

11 SOAP +

REST Oracle 19c EE

X-tee andmejälgija 11 SOAP PostgreSQL

RINA Facade 11 REST RabbitMQ Oracle 19c EE

Protsessimootor 11 SOAP

Oracle AQ Oracle 19c EE

X-tee turvaserver

SOAP

Failihoidla 11

Oracle 19c EE

TUUM Andmebaas

Oracle 19c EE

7. Tuleviku visioon

7.1. Läbiviidud arhitektuurianalüüsi käigus loodi tänaste probleemide adresseerimiseks uus

arhitektuuriline visioon, millega kaasnevad tähtsamad muudatused on:

7.1.1. 2018 arendatud olemasolevate rakenduste (ametnikurakendus, X-tee teenusetäitja ja protsessimootori "monoliidid") kõrvale on hakatud arendama igale valdkonnale eraldi koodibaasi ja rakendusi. Uuemad äriteenused on arendatud jälgides mikroteenuste arhitektuuri põhimõtteid. Tasapisi on olemasolevatest teenuste monoliidist välja tõstetud funktsionaalselt iseseisvaid tükke ning need realiseeritud eraldi mikroteenustena. Kavas on seda mustrit jätkata ning edasistes arendustes monoliidi osakaalu järk-järgult veelgi vähendada.

7.1.2. Rakenduste paigaldusel võetakse kasutusele konteinerlahendused (Kubernetes). Uute rakenduste loomisel võetakse kohe arvesse, et neid saaks paigaldada ka konteinerina.

7.1.2.1. NB: täna (02.2024) ei ole Kubernetes veel toodangus. Tänase teenusetäitjaga käivad läbirääkimised Kubernetese klastri seadistuse ning halduse vastutuste piiride üle.

7.1.2.2. Seni tarnitud komponentide liigutamisega Kubernetese konteinerplatvormile on plaanis alustada 2025 aastal.

7.1.2.3. SKAIS2 rakenduse kolimine Kubernetese klastrisse toimub järk järgult üksikute ärikomponentide kaupa, kuni lõpuks on kõik SKAIS2 komponendid Kubernetese klastris.

7.1.3. Suurem rõhk continuous integration'ile ja automaattestimisele. 7.1.3.1. Seniste tarneprotsesside optimeerimine ja automatiseerimine. 7.1.3.2. Keskkonna konfiguratsioonide ühtlustamine ja versioneerimine.

8. Teenuse tehniline kirjeldus

8.1. Nõuded serveriruumile ja infrastruktuurile 8.1.1. Täitja majutab tellija infosüsteemi kahes füüsiliselt eraldi asukohas ja eraldi aadressidel

paiknevas serveriruumis. Serveriruumid ja nendevahelised ühendused peavad

paiknema Eesti Vabariigi territooriumil ja serveriruumide minimaalne nõutud geograafiline vahemaa vähemalt 1 km.

8.1.3. Täitja tagab SKAIS2 infosüsteemile turvatud (SSL) välise andmesideühenduse kiirusega vähemalt 100 Mbps (megabitti sekundis) ja serveriruumide vahel füüsilise, turvatud (VPN) dubleeritud ühenduse kiirusega vähemalt 1 Gbps (gigabitti sekundis).

8.1.4. Andmesideühenduse (internetiteenuse) täitja peab olema Eesti Interneti SA poolt akrediteeritud.

8.1.7. Täitja tagab eraldatud turvadomeenid süsteemi tuumale, Ametnikurakendusele, Avalikule rakendusele ja eBS rakendusele. Täitja kirjeldab pakkumises vastavat tehnilist lahendust.

8.1.8. Täitja peab kasutama riistvara, millel töötab ainult tellija infosüsteem. Pakutaval riistvaral ei tohi töötada samal ajal kolmandate osapoolte infosüsteemid. Samuti ei tohi olla kolmandatel osapooltel ligipääse pakutavale riistvarale ja operatsioonisüsteemile.

8.2. SKAIS2 infosüsteemi majutus- ja tugiteenuste üldised (miinimum) nõuded 8.2.1. Täitja kohustub tagama SKAIS2 infosüsteemi kasutamise võimaluse veebikeskkonnas

ning lepingu kehtivuse perioodil kindlustama keskkondade nõuetekohase (hankedokumendis ja teenusepassis kirjeldatud) funktsioneerimise.

8.2.2. Täitja tagab SKAIS2 infosüsteemi järgmised majutus- ja tugiteenused: 8.2.2.1. Serverite, võrgu- ja salvestusseadmete ressursid. 8.2.2.2. Andmebaaside administreerimine ja monitooring. 8.2.2.3. Rakenduste administreerimine ja monitooring. 8.2.2.4. Infrastruktuuri administreerimine ja monitooring. 8.2.2.5. X-tee turvaserverite (x-tee v6) administreerimine, versiooniuuendused ja

sellega kaasnevad tööd, kaasa arvatud riistvaralist turvalist allkirjastamist võimaldavat (SSCD) seadet. Majutaja tagab tehnilise võimekuse osutada teenust vastavalt kehtivatele x-tee nõuetele. SKAIS2 tarkvaras kasutatakse digitembeldamist, mille tehnilises realisatsioonis kasutatakse RIA soovituste mõttes vähemalt keskklassi SSCD seadet (HSM), mis tagab vähemalt 20 päringut/s. HSM seadme tagab Täitja majutusteenuse koosseisus.

8.2.2.6. Muudatuste haldus. 8.2.2.7. Konsultatsioonid ja parendusettepanekud. 8.2.2.8. Muud ühekordsed tegevused ehk lisatööd. 8.2.2.9. Teenuse lõpetamisega seotud tööd lepingu lõppemisel.

8.2.4. SKAIS2 infosüsteemi Oracle andmebaaside vaheliseks andmete reaalajas sünkroniseerimiseks peab Täitja kasutatama Oracle Data Guard tarkvara. Oracle Active Data Guard tarkvara võetakse kasutusele vajadusepõhiselt, mille kasutuselevõtu tingimused lepitakse eraldi kokku teenuseosutajaga.

8.2.5. eBS infosüsteemi Oracle andmebaaside vaheliseks andmete reaalajas sünkroniseerimiseks peab Täitja kasutatama Oracle Data Guard tarkvara.

8.2.6. Vältimaks SKAIS2 infosüsteemi ülekoormamist ei tohi Oracle BI Publisher aruandluskeskkond andmeid pärida aktiivsest SKAIS2 infosüsteemi andmebaasist.

8.2.7. Lepingu lõppedes kooskõlastatakse andmete uude majutuskeskkonda migreerimise ja seejärel hävitamise protsess Tellija ja Täitja vahel. Andmete ülekolimise ja hävitamise järgselt vormistab majutusteenuse osutaja akti, millega kinnitatakse, et andmed on hävitatud.

8.2.8. Teenuse osutaja vahetumisel, vormistatakse andmete ülekolimise (migratsiooni) läbiviimise järgselt kolmepoolne üleandmis-vastuvõtu akt (andja, vastuvõtja, omanik).

8.2.9. Teenuse lõppedes, uude keskkonda andmete migratsiooni ettevalmistamine ja läbiviimisel abi osutamine (täitja pädevuse ulatuses) on majutusteenuse osa ja ei ole eraldi tasustatav.

8.3. Nõuded andmete hoidmisele 8.3.1. Kõik infosüsteemis töödeldavad andmed (andmebaasis ja rakendusserverites) peavad

8.4. X-tee turvaserverid 8.4.1. SKAIS2 infosüsteemis on kasutusel x-tee versioon 6 raamistik. 8.4.2. Täitja tagab eraldi x-tee turvaserverid töökeskkonna, toodangueelse keskkonna ja

testkeskkonna tarbeks. Testkeskkond on liidestatud X-tee testkeskkonnaga; toodangueelne ja toodangukeskkond on liidestatud X-tee töökeskkonnaga.

8.4.3. Täitja tagab x-tee ligipääsu dubleeritud serveriruumis, sealhulgas olukorras, kus primaarne serveriruum ei ole kasutatav ja töökeskkond on üle kolitud.

8.4.4. Täitja osutab Tellijale turvaserverite administreerimisteenust. 8.4.5. Täitja peab omama x-tee turvaserveri logimise lahendus, mis võimaldab väljastada

regulaarselt logiandmed tellijale. 8.5. Muudatuste haldus

8.5.1. Arendusmuudatuste paigalduse õigus on ainult täitjal, kui ei lepita kokku teisiti. 8.5.2. Arendusmuudatused valmistab ette täitja ja edastab paketeeritult koos

paigaldusjuhendiga paigaldamiseks toodangu-, toodangueelsesse ja testkeskkonda. Paigalduspakettide, juhendite jm vajaliku informatsiooni edastamiseks ja paigaldustega seotud tegevuste dokumenteerimiseks, kasutatakse tellija tööde/projektide juhtimise keskkonda Jira.

8.5.3. Teenusetäitja paigaldab arendusmuudatusi lepingu raames vastavalt teenuse passile ja tarne juhendile.

8.5.4. Toodangukeskkonda ja toodangueelsesse keskkonda tehakse üldjuhul kuni 4 arendusmuudatuse tarnet ja 4 veaparandustarnet kuus. Testkeskkonda tehakse üldjuhul kuni 12 arendusmuudatuse tarnet ja 12 veaparandustarnet kuus. Arendusmuudatusi töökeskkonda viiakse sisse väljaspool aktiivset tööaega.

8.5.5. Teenusetäitja peab vastavalt tellimusele käivitama parandusskripte vigade tuvastamiseks ja parandamiseks.

8.5.6. Arendusmuudatuste paigalduse aja kooskõlastab täitja tellijaga. 8.5.7. Täitja poolt arendusmuudatuse paigalduse ebaõnnestumisel vastutab täitja süsteemi

taastamise (rollback) eest.

8.5.8. Täitja uuendab toodangueelse ja testkeskkonna andmeid toodangukeskkonna andmetega tellija tellimusel kui tarnejuhend või arendusprotsessi etapp (näiteks andmemigratsiooni ettevalmistamine) seda ette näeb. Andmeuuenduse läbiviimise aeg ja maht lepitakse eraldi kokku.

8.5.9. Teenusetäitja tagab tellija tellimisel arenduspartneritele ligipääsu test- ja toodangueelsele keskkonnale (andmebaasile, rakendusserverile) 2 tööpäeva jooksul.

8.5.10. Teenusetäitja tagab tellija tellimisel arenduspartneritele ligipääsu sulgemise test- ja toodangueelsele keskkonnale esimesel võimalusel, kuid mitte hiljem kui 2 tööpäeva jooksul.

8.5.11. Täitja peab tagama Tellija tellimisel (andme)halduritele / rakenduse administraatoritele ligipääsud kõikide SKAIS2 keskkondade serverite operatsioonisüsteemi konfiguratsioonifailidele ja andmebaasidele.

8.6. Varundamine ja teenuse taastamine 8.6.1. Täitja teeb majutuskeskkonnas olevatest süsteemidest regulaarselt varukoopiaid

selliselt, et oleks tagatud teenuse passis sätestatud tingimuste täitmine. Täitja peab pakkumises kirjeldama, et milliste vahendite ja meetoditega tehakse varukoopiaid.

8.6.2. Varukoopiaid tehakse rakendusi seiskamata st, et Tellija infosüsteemide käideldavus ei ole varukoopiate tegemise ajal mõjutatud. Varundust teostatakse väljaspool infosüsteemi tööaega.

8.6.6. Andmekadu põhjustavat intsidenti käsitletakse kui erakorralist intsidenti. Erakorralise intsidendi korral on lubatud teenuse järjestikune seisak kuni 4 tundi ja summaarne seisak kuni 4 tundi nädalas ja kuni 6 tundi kalendrikuus. Pärast intsidendi lahendamist ja/või andmete taastamist esitab täitja tellijale detailse raporti, kus toob välja intsidendi põhjuse, mis põhjustas andmekadu ning meetmed selliste juhtumite vältimiseks või esinemise tõenäosuse vähendamiseks tulevikus.

8.7. Monitooring 8.7.1. Täitja tagab tsentraliseeritud tehnilise toe teenuse, mis on avatud 24 tundi ööpäevas ja

seitse päeva nädalas, mille kaudu sooritatakse mitmesuguseid süsteemiga seotud järelevalve, muudatuste ja veahalduse menetlustoiminguid.

8.7.2. Tehnilise toe teenuseid osutatakse osana majutusteenustest, kus kõik süsteemihoiatused saadetakse tsentraliseeritud 24 tundi toimivale tehnilisele toele (sh

võrgu, serveri ja rakenduse hoiatused). Rakenduste ja teiste SKAIS2 komponentide monitooringuinfo hoitakse Graylog logihalduse keskkonnas. Graylog logihalduse keskkond (on-premise) on majutusteenuse osa.

8.7.3. Kõik keskkonnad peavad olema Täitja poolt monitooritud kogu lepinguperioodi vältel. 8.7.4. Täitja võimaldab Tellijale ja Tellija poolt nimetatud arendajale juurdepääsu

monitooringuinfole või edastab monitooringuteated Tellija poolt etteantud meiliaadressile.

8.7.5. Täitja installeerib vajadusel või Tellija palvel serveritesse täiendavad monitooringuagendid, mis koguvad infot serverite ja rakenduste seisundi kohta. Tellijal on täna kasutusel monitooringu süsteem Prometheus ja Grafana.

8.7.6. Täitja monitoorib serverites asuvate infosüsteemide tööd vähemalt järgmiste komponentide osas:

8.7.7. SKAIS2 infosüsteemi rakenduse monitooring 8.7.7.1. Täitja poolset SKAIS2 rakenduse monitooringut ei nõuta. Täitjal peab olema

valmisolek integreerida oma keskkonda Tellija poolt kasututavad rakenduse monitooringu vahendid (agendid vms).

8.8. Teenuse tehniline tugi 8.8.1. Täitja peab tagama kasutajatoe (ühtne kontaktpunkt, telefoni number, e-mail ja/või

avalik portaal) vastavalt Teenuse passis toodud nõuetele. 8.8.2. Täitja peab teavitama Tellijat kriitilistest ja keskmise taseme vigadest koheselt ja

asuma teenuse nõutud tingimustele vastavust taastama. 8.8.3. Kui tõrget ei ole võimalik teenuse passis nõutud aja jooksul lahendada, peab Täitja

esitama põhjendused ja lahendusettepanekud. 8.8.4. Kriitilise taseme tõrkeks loetakse olukorda, kus SKAIS2 toodangukeskkonna

tervikuna või oluliste komponentide, s.h andmevahetused teiste infosüsteemidega, kasutamine ei ole võimalik.

8.8.5. Keskmise taseme tõrkeks loetakse olukorda, kus SKAIS2 toodangukeskkonna kasutamine on oluliselt häiritud.

8.8.6. Madala taseme tõrkeks loetakse olukorda, kus SKAIS2 toodangukeskkonna kasutamine on võimalik, kuid on häiritud.

8.9. Aruandlus ja infovahetus 8.9.1. Täitja esitab majutusteenuse osutamise kohta igakuiselt ülevaate eelmise kuu kohta,

mis sisaldab vähemalt järgmist informatsiooni: 8.9.1.1. Süsteemi komponentide käideldavus vastavalt teenuste passi nõuetele. 8.9.1.2. Perioodi vältel toimunud intsidendid koos algus- ja lõpuajaga, juurpõhjusega

(kui on selgunud) ning kirjeldusega, kuidas neid edaspidi vältida. 8.9.1.3. Perioodi vältel tehtud plaanilised tööd. 8.9.1.4. Muudatuste logi. 8.9.1.5. Tellija poolt perioodi jooksul esitatud pöördumiste staatus, mis sisaldab ka

lahendamata pöördumisi eelmistest perioodidest. 8.9.1.6. Täitja poolsed ettepanekud infosüsteemi ja majutuse parendamiseks ning

teostamiskava.

8.9.2. Aruandlus peab olema tellija kontaktisikutele kättesaadavaks tehtud veebi kaudu või e-kirja teel.

8.9.3. Täitja peab võimaldama tellijal tellida tellimustööna täiendava tasu eest ühekordseid raporteid nt andmebaasi detailseid koormusraporteid.

8.9.4. Täitja ja tellija vaheline töökeel on eesti keel.

III. STAR arhitektuuridokument

1. Sissejuhatus

1.1. Antud dokument kirjeldab STAR infosüsteemi arhitektuuri, sisaldades antud süsteemi komponentide kirjeldust, nende omavahelist suhtlemist, paigaldusvaadet ning kirjeldust süsteemi ning teda ümbritsevate keskkondade vahel.

2. Süsteemi taust

2.1. Sotsiaalkindlustusameti infosüsteem STAR on riigi keskne andmeregister, mis on asutatud juhtumikorralduse põhimõttel läbiviidava sotsiaaltöö korraldamiseks ja mille põhikasutajateks on kohalike omavalitsuste sotsiaaltöö spetsialistid ja sotsiaalteenuseid osutavate ettevõtete esindajad. STAR-i peetakse seadustest tulenevate Sotsiaalkindlustusameti avalike ülesannete täitmise eesmärgil.

2.2. STARis on toimumas tehnoloogiline siirdumine monoliitrakendusest mikroteenustele põhinevale rakendusele. Siirdumine toimub väikeste sammudega ja paralleelselt on kasutusel monoliitrakendus (STAR1) ja mikroteenustel põhinev rakendus (STAR2). STAR1 ja STAR2 suhtlevad omavahel läbi API liideste. Kummalgi rakendusel on oma kasutajaliides.

2.3. STAR1 koosneb kolmest eraldi paigaldatavast rakendusest: 2.4. Ametnikurakendus (star-web.war) - peamine rakendus. KOVi ja SKA menetluste äriloogika

juhtimine; 2.5. X-tee provider (STARXteeProvider6.war) - pakub X-tee teenuseid välistele

infosüsteemidele; 2.6. NGTS seire ankeet () - lihtne ankeedi rakendus Noortegarantii tugisüsteemi (NGTS) seire

teostamiseks. 2.7. Andmeid hoitakse keskses Oracle 19c andmebaasis. 2.8. STAR2 mikroteenused on veel algses arengu järgus. Valmis on tehtud kolmes

küpsusastmes teenuseid: 2.9. Iseseisvad mikroteenused - Kogu vajalik funktsionaalsus on arendatud ühe mikroteenuse

sisse. Mikroteenusel on oma andmebaas. 2.10. Hübriidmikroteenus - Vajalik funktsionaalsus on arendatud mikroteenuse sisse.

Mikroteenusel on oma andmebaas. Aga ta sõltub mingil määral STAR1 andmetest ja äriloogikast.

2.11. Proxymikroteenused - Mikroteenus ei sisalda äriloogikat ega oma oma andmebaasi. Vajaliku äriloogika ja andmed asuvad STAR1 rakenduses. Proxy mikroteenus vahendab STAR1 loogikat ja andmeid.

2.12. Edasistes arendustest peavad hübriid ja proxy mikroteenused muutuma iseseisvateks mikroteenusteks.

2.13. Iseteeninduse broneeringute rakendus on osa Sotsiaalkindlusameti iseteenindusest. Kuna Sotsiaalkindlustusameti iseteeninduse põhirakendus ei toeta mikrofrontende, siis broneeringute süsteem on arendatud eraldi iseseisva rakendusena. Iseteeninduse broneeringute rakendus baseerub mikroteenustel. STAR ja SKAIS infosüsteemidega toimub andmevahetus üle X-tee.

2.14. Infosüsteemi STAR majutuskeskkond koosneb kolmest võrgu tasemele teineteisest lahusolevast keskkonnast. Kõiki keskkonnad on üles ehitatud sarnase arhitektuuri ja komponentidega va. testkeskkond, millel puudub vajadus teise dubleeriva õla järele. Allpool dokumendis on komponentide tasemel piisava detailsusega lahti kirjutatud STAR loogiline arhitektuuriline ülesehitus kirjeldamaks praeguse süsteemi toimimist ja võimaldamaks jätkusuutlikku arengut tulenevalt Sotsiaalkindlustusameti arenduse soovidest.

3. STAR komponentdiagramm

3.1. Järgnev skeem kirjeldab STAR infosüsteemis paiknevaid komponente ning nende vahelist suhtlust.

3.2. Veebiportaal – Ametnikele mõeldud veebirakendus 3.3. SSO ja KeyCloak – Autentimislahendus süsteemi möldimiseks. 3.4. Turvaserver – Liidestus X-Teega. 3.5. Andmebaas – Oracle Database Enterprise Edition, STAR andmestik.

4. Majutatavad teenuse komponendid

4.1. Andmebaas 4.1.1. Oracle Database 19c Enterprise Edition.

4.2. Veebiportaal 4.2.1. KOV ametnikele mõeldud veebirakendused 4.2.2. Tüüp: teenuseid pakkuv veebilehekülg 4.2.3. Kasutatud protokoll: https 4.2.4. Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad.

4.3. Adapterserver 4.3.1. Kasutatakse x-tee teenuste vahendamiseks x-teele 4.3.2. Tüüp: sünkroonne ja asünkroonne teenus; süsteemne taustprotsess 4.3.3. Kasutatud protokoll: integreeritud süsteemi osa

4.4. Digitempel 4.4.1. SSCD seade võimaldamaks turvalist allkirjastamist. SSCD seade peab võimaldama

teostada 100 allkirjastamist minutis. 4.4.2. Tüüp: Daemon protsess 4.4.3. Kasutatud protokoll: jdbc; https;

4.5. Turvaserver

4.5.1. X-tee turvaserver, vajalik X-teel andmete vahetamiseks. 4.5.2. Kasutatud protokoll: soap

5. Välised liidestused

5.1. SSO (KeyCloak) 5.1.1. Autentimislahendus, liidestatud RIA TARA keskkonnaga, et pakkuda ID-kaardiga,

Mobiil-ID ja SMART-ID sisselogimist 5.1.2. karbitoode: https://www.keycloak.org/

5.2. Sertifitseerimiskeskus 5.2.1. Digiallkirjade kehtivuskinnitus 5.2.2. Tüüp: sünkroonne teenus

5.3. Pank 5.3.1. Väljamaksete edastamine panka 5.3.2. Tüüp: asünkroonne gateway 5.3.3. Kasutatud protokoll: SOAP

5.4. X-tee 5.4.1. Erinevate andmekogudega suhtlus 5.4.2. Tüüp: sünkroonne/asünkroonne 5.4.3. Kasutatud protokoll: SOAP

6. Süsteemi arhitektuuris kasutatavad tehnoloogiad/tarkvarad

6.1. Serverite operatsioonisüsteem 6.1.1. Serverite operatsioonisüsteemi tarkvarad peavad olema kaetud tootjapoolse

tarkvaratoega lepingu perioodi vältel. 6.1.2. Operatsioonisüsteem: Red Hat Enterprise Linux 7 (RHEL) / Oracle Enterprise Linux 7

(OEL). 6.1.3. X-tee turvaserveritel Ubuntu linux LTS (vastavalt RIA nõuetele). 6.1.4. Vajalikud litsentsid tagab Täitja.

6.2. Apache HTTP Server Versioon: 2.4. 6.2.1. Konfiguratsioon ja nõuded: SSL, ID-Kaardi sertifikaadi tuvastamine (ssl

konfiguratsioon). 6.2.2. Operatsioonisüsteem: Red Hat Enterprise Linux 7 (RHEL) 6.2.3. Vajalikud SSL sertifikaadid tagab Tellija.

6.3. Apache Tomcat Versioon: 8.x 6.3.1. Konfiguratsioon ja nõuded: - 6.3.2. Operatsioonisüsteem: Red Hat Enterprise Linux 7 (RHEL)

6.4. Oracle Database Standard Edition 19c 6.4.1. Konfiguratsioon ja nõuded: klasterdatud andmebaas. 6.4.2. Operatsioonisüsteem: Oracle Enterprise Linux 7 (OEL). 6.4.3.Andmebaasi eeldatav stardimaht (täna olemasolev andmestik) 1TB 6.4.4. Tellija tagab 2 (kaks) Oracle Database Standard CPU litsentsi. Süsteemi arengust

tingitud vajaduse korral tagab lisalitsentsid Tellija.

7. STAR2 ametniku rakenduse arhitektuur – mikroteenused

7.1. Esimene etapp uuele arhitektuurile üleminekul saab olema lapse abivajaduse hindamise projekt (LAEH), mille arendused valmivad suvel 2022. Analüüsi üks eesmärk oli välja töötada STAR uue arhitektuuri kontseptsioon ja põhimõtted ning kaardistada esimeses etapis realiseeritavad arhitektuuritööd.

7.2. STAR2 ametniku rakenduse arhitektuur:

7.3. Sotsiaalkindlustusameti iseteeninduse broneeringute rakendus:

7.4. STAR tarkvarad, raamistikud ja platvormid

7.4.1. STAR1 monoliitrakenduse komponendid:

Tarkvara Toodang Prelive Test Arendus

Apache HTTPD/2.4.6 x x x

Apache Tomcat/8.5.4 x x x x

JAVA/openjdk version "1.8.0_111"

x x x x

Oracle Database 19c - 64bit x x x

LiquiBase x x x x

Oracle 18XE x

7.4.2. STAR ja iseteeninduse mikroteenuste keskkond:

Tarkvara Toodang Prelive Test Arendus

Java/openjdk 17 x x x x

Spring Boot x x x x

Next.js (React) x x x x

PostgreSQL 14 x x x x

Kubernetes x x x x

FlyWay x x x x

Traefik Ingress x x x

Nginx Ingress x

RabbitMq x x x x

8. Teenuse tehniline kirjeldus

8.1. Nõuded serveriruumile ja infrastruktuurile 8.1.1. Täitja majutab Tellija infosüsteemi kahes füüsiliselt eraldi asukohas ja eraldi

8.1.3. Täitja tagab STAR infosüsteemile turvatud (SSL) välise andmesideühenduse kiirusega vähemalt 100 Mbps (megabitti sekundis) ja serveriruumide vahel füüsilise, turvatud (VPN) dubleeritud ühenduse kiirusega vähemalt 1 Gbps (gigabitti sekundis).

8.1.4. Andmesideühenduse (internetiteenuse) täitja peab olema Eesti Interneti SA poolt akrediteeritud.

8.1.6. Täitja serveriruumid peavad olema ühendatud Tellija serveriruumidega läbi VPN ühenduse kiirusega vähemalt 1Gb/s. Tellija serveriruumid asuvad serverimajutuskeskustes kahes erinevas lokatsioonis Eesti Vabariigis.

8.2. STAR infosüsteemi majutus- ja tugiteenuste üldised (miinimum) nõuded 8.2.1. Täitja kohustub tagama STAR infosüsteemi kasutamise võimaluse veebikeskkonnas

ning lepingu kehtivuse perioodil kindlustama keskkondade nõuetekohase (hankedokumendis ja teenusepassis kirjeldatud) funktsioneerimise.

8.2.2. Täitja tagab STAR infosüsteemi järgmised majutus- ja tugiteenused: 8.2.2.1. Serverite, võrgu- ja salvestusseadmete ressursid. 8.2.2.2. Andmebaaside administreerimine ja monitooring. 8.2.2.3. Infrastruktuuri administreerimine ja monitooring. 8.2.2.4. Muudatuste haldus. 8.2.2.5. Konsultatsioonid ja parendusettepanekud. 8.2.2.6. Muud ühekordsed tegevused ehk lisatööd. 8.2.2.7. Teenuse lõpetamisega seotud tööd lepingu lõppemisel.

8.2.4. STAR infosüsteemi Oracle andmebaaside vaheliseks andmete reaalajas sünkroniseerimiseks peab Täitja kasutatama Oracle Data Guard tarkvara. Oracle Active Data Guard tarkvara võetakse kasutusele vajadusepõhiselt, mille kasutuselevõtu tingimused lepitakse eraldi kokku teenuseosutajaga.

8.2.5. Tellija poolt sätestatud STAR majutuse mittefunktsionaalsed nõuded on kirjeldatud dokumendis TEHIK MFN.

8.2.6. Lepingu lõppedes kooskõlastatakse andmete uude majutuskeskkonda migreerimise ja seejärel hävitamise protsess Tellija ja Täitja vahel. Andmete ülekolimise ja hävitamise järgselt vormistab majutusteenuse osutaja akti, millega kinnitatakse, et andmed on hävitatud.

8.2.7. Teenuse osutaja vahetumisel vormistatakse andmete ülekolimise (migratsiooni) läbiviimise järgselt kolmepoolne üleandmis-vastuvõtu akt (andja, vastuvõtja, omanik).

8.2.8. Teenuse lõppedes, uude keskkonda andmete migratsiooni ettevalmistamine ja läbiviimisel abi osutamine (Täitja pädevuse ulatuses) on majutusteenuse osa ja ei ole eraldi tasustatav.

8.3. Nõuded andmete hoidmisele 8.3.1. Kõik infosüsteemis töödeldavad andmed (andmebaasis ja rakendusserverites) peavad

8.4. X-tee turvaserverid ja liidetus 8.4.1. STAR infosüsteemis on kasutusel x-tee versioon 6 raamistik. 8.4.2. X-tee eraldi turvaserverid töökeskkonna, toodangueelse keskkonna ja

testkeskkonna tagab Täitja.

8.4.3. Majutuskeskkonnas peab olema STAR jaoks seadistatud eraldi adapterserverid tootmis-, toodangueelse ja testkeskkonnale (arenduse x-tee päringud suunatakse testkeskkonda) STAR andmekogu päringute vahendamiseks telistele süsteemidele läbi x-tee.

8.4.4. Turvaserverid peavad olema valmis võimalikeks lisanduvateks liidesteks. 8.4.5. Teenuse täitja peab tagama vajalike muudatuste rakendamise x-tee turva – ja

adapterserverites vastavalt lisanduvate või muutuvate liideste vajadusele. 8.4.6. Tootmis- ja testkeskkonnas peab olema paigaldatud x-tee andmevahetuse

jälgimiseks RIA andmejälgija (https://github.com/e-gov/AJ ) 8.5. Muudatuste haldus

8.5.1. Arendusmuudatuste paigalduse õigustoodangu- ja toodangueelsesse keskkonda on ainult täitjal, kui ei lepita kokku teisiti. Test- ja Koolituskeskkonda võib paigaldusi teostada Teenuse täitja, arendaja ja Tellija.

8.5.2. Arendusmuudatused valmistab ette Arendaja ja edastab paketeeritult koos paigaldusjuhendiga paigaldamiseks toodangu- ja toodangueelsesse keskkonda. Paigalduspakettide, juhendite jm vajaliku informatsiooni edastamiseks ja paigaldustega seotud tegevuste dokumenteerimiseks, kasutatakse tellija tööde/projektide juhtimise keskkonda Jira.

8.5.3. Teenusetäitja paigaldab arendusmuudatusi lepingu raames vastavalt teenuse passile. 8.5.4. Toodangukeskkonda tehakse üldjuhul kuni 8 arendusmuudatuse tarnet kuus.

Toodangueelsesse keskkonda kuni 16 arendusmuudatuse tarnet kuus. Test- ja koolituskeskkonda tehakse üldjuhul kuni 20 arendusmuudatuse tarnet kuus. Arendusmuudatusi töökeskkonda viiakse sisse väljaspool aktiivset tööaega.

8.5.5. Teenusetäitja peab vastavalt tellimusele käivitama parandusskripte vigade tuvastamiseks ja parandamiseks.

8.5.6. Arendusmuudatuste paigalduse aja kooskõlastab Täitja Tellijaga. 8.5.7. Täitja poolt arendusmuudatuse paigalduse ebaõnnestumisel vastutab Täitja süsteemi

taastamise (rollback) eest. 8.5.8. Täitja uuendab toodangueelse ja testkeskkonna andmeid toodangukeskkonna

andmetega Tellija tellimusel kui tarnejuhend seda ette näeb, kuid mitte rohkem kui punktis 8.5.4 kirjeldatud tarnete arv.

8.5.9. Täitja peab värskendama STAR statistikabaasi iga öö. Andmed laetakse STAR toodangukeskkonna andmebaasist.

8.5.10. Teenusetäitja tagab Tellija tellimisel arenduspartneritele ligipääsu test- ja toodangueelsele keskkonnale (andmebaasile, rakendusserverile) 2 tööpäeva jooksul.

8.5.11. Teenusetäitja tagab tellija tellimisel arenduspartneritele ligipääsu sulgemise test- ja toodangueelsele keskkonnale esimesel võimalusel, kuid mitte hiljem kui 2 tööpäeva jooksul.

8.5.12. Täitja peab kindlustama Tellija tellimisel (andme)halduritele / rakenduse administraatoritele lugemisõigustes (read only) ligipääsud kõikide STAR keskkondade serverite operatsioonisüsteemi konfiguratsioonifailidele ja andmebaasidele.

8.6. Varundamine ja teenuse taastamine 8.6.1. Täitja teeb majutuskeskkonnas olevatest süsteemidest regulaarselt varukoopiaid

selliselt, et oleks tagatud teenuse passis sätestatud tingimuste täitmine. Täitja peab pakkumises kirjeldama, et milliste vahendite ja meetoditega tehakse varukoopiaid.

8.6.2. Varukoopiaid tehakse rakendusi seiskamata st, et tellija infosüsteemide käideldavus ei ole varukoopiate tegemise ajal mõjutatud. Varundust teostatakse väljaspool infosüsteemi tööaega.

8.6.4. Täitja on kohustatud hoidma töökeskkonna varundatud andmeid järgnevalt:

8.6.4.1. Vähemalt kahe viimase kuukoopia. 8.6.4.2. Vähemalt neli viimast nädalakoopiat. 8.6.4.3. Vähemalt viis viimast tööpäevakoopiat.

8.6.7. Täitja töötab pärast iga keskkonna käivitamist ühe kuu jooksul välja vastava keskkonna taasteplaani ja esitab selle tellijale ülevaatamiseks ja kinnitamiseks. Taasteplaan peab sisaldama tegevuskava ja süsteemi üldist arhitektuuri kirjeldust visuaalsel kujul. Olulised infrastruktuuri komponendid (serverid, võrguseadmed jne) peavad olema kirjalikult lahti seletatud.

8.6.8. Täitja testib taasteplaani ajakohasust, kui toimub muudatus tellija infosüsteemiga seotud infrastruktuuris, kuid mitte harvemini kui üks kord aastas. Täitja kooskõlastab tellijaga testi läbiviimise aja ning esitab Tellijale pärast testi läbiviimist raporti, kus märgib ära taasteplaani vastavuse tegelikule olukorrale ja plaanist leitud puudused. Puudused tuleb kõrvaldada Tellijaga kokkuleppel mõistliku aja jooksul ning seejärel korraldada uus taasteplaani test.

8.7. Monitooring 8.7.1. Täitja tagab tsentraliseeritud tehnilise toe teenuse, mis on avatud 24 tundi ööpäevas ja

seitse päeva nädalas, mille kaudu sooritatakse mitmesuguseid süsteemiga seotud järelevalve, muudatuste ja veahalduse menetlustoiminguid.

8.7.3. Kõik keskkonnad peavad olema Täitja poolt monitooritud kogu lepinguperioodi vältel. 8.7.4. Täitja võimaldab Tellijale ja Tellija poolt nimetatud arendajale juurdepääsu

monitooringuinfole või edastab monitooringuteated Tellija poolt etteantud meiliaadressile.

8.7.5. STAR logidele peab Tellijal olema ligipääs üle veebiliidese. Logide haldus peab töötama täitja majutuse keskkonnas (on premise).

8.7.6. Täitja installeerib vajadusel või Tellija palvel serveritesse täiendavad monitooringuagendid, mis koguvad infot serverite ja rakenduste seisundi kohta. Tellijal on kasutusel monitooringu süsteem Prometheus ja Grafana.

8.7.7. Täitja monitoorib serverites asuvate infosüsteemide tööd vähemalt järgmiste komponentide osas:

8.7.7.1. Andmesideühenduse olemasolu tellija serverite ja infosüsteemide vahel. 8.7.7.2. Serverite riistvaraliste komponentide töökorras olek. 8.7.7.3. Serverite protsessorite ja mälukasutus. 8.7.7.4.Kõvaketaste täituvus. 8.7.7.5. Süsteemi load (UNIX süsteemide puhul). 8.7.7.6. Andmebaasisüsteemi töökorras olek. 8.7.7.7. Andmebaasile eraldatud ressursside olemasolu. 8.7.7.8.Varukoopiate tegemise õnnestumine. 8.7.7.9. Monitooringusüsteemi töökorras olek.

8.7.8. STAR infosüsteemi rakenduste monitooring

8.7.8.1. Täitja poolset STAR rakenduse monitooringut ei nõuta. Täitjal peab olema valmisolek integreerida oma keskkonda Tellija poolt kasututavad rakenduse monitooringu vahendid (agendid vms).

8.7.9. Teenuse tehniline tugi 8.7.9.1. Täitja peab tagama kasutajatoe (ühtne kontaktpunkt, telefoni number, e-

mail ja/või avalik portaal) vastavalt Teenuse passis toodud nõuetele. 8.7.9.2. Täitja peab teavitama Tellijat kriitilistest ja keskmise taseme vigadest

koheselt ja asuma teenuse nõutud tingimustele vastavust taastama. 8.7.9.3. Kui tõrget ei ole võimalik teenuse passis nõutud aja jooksul lahendada, peab

Täitja esitama põhjendused ja lahendusettepanekud. 8.7.9.4. Kriitilise taseme tõrkeks loetakse olukorda, kus STAR toodangukeskkonna

tervikuna või oluliste komponentide, s.h andmevahetused teiste infosüsteemidega, kasutamine ei ole võimalik.

8.7.9.5. Keskmise taseme tõrkeks loetakse olukorda, kus STAR toodangukeskkonna kasutamine on oluliselt häiritud.

8.7.9.6. Madala taseme tõrkeks loetakse olukorda, kus STAR toodangukeskkonna kasutamine on võimalik, kuid on häiritud.

8.7.10. Aruandlus ja infovahetus 8.7.10.1. Täitja esitab majutusteenuse osutamise kohta igakuiselt ülevaate eelmise

kuu kohta, mis sisaldab vähemalt järgmist informatsiooni: 8.7.10.1.1. Süsteemi komponentide käideldavus vastavalt teenuste passi

nõuetele. 8.7.10.1.2. Perioodi vältel toimunud intsidendid koos algus- ja lõpuajaga,

juurpõhjusega (kui on selgunud) ning kirjeldusega, kuidas neid edaspidi vältida.

8.7.10.1.3. Perioodi vältel tehtud plaanilised tööd. 8.7.10.1.4. Muudatuste logi. 8.7.10.1.5. Tellija poolt perioodi jooksul esitatud pöördumiste staatus, mis

sisaldab ka lahendamata pöördumisi eelmistest perioodidest. 8.7.10.1.6. Täitja poolsed ettepanekud infosüsteemi ja majutuse parendamiseks

ning teostamiskava. 8.7.10.2. Aruandlus peab olema Tellija kontaktisikutele kättesaadavaks tehtud veebi

kaudu või e-kirja teel. 8.7.10.3. Täitja peab võimaldama Tellijal tellida tellimustööna täiendava tasu eest

ühekordseid raporteid nt andmebaasi detailseid koormusraporteid. 8.7.10.4. Täitja ja Tellija vaheline töökeel on eesti keel.

8.8. Vajalikud ligipääsud Tellijale 8.8.1. Teenuse täitja ja Tellija võrkude vahele tuleb rajada VPN tunnel. Kogu osapoolte

vaheline andmete liikumine peab toimuma läbi VPN tunneli. 8.8.2. Teenuse täitja peab kindlustama ühenduse Tellija SSO teenusele. 8.8.3. Teenuse täitja peab kindlustama Tellija andmeaida andmete laadimise süsteemile

(Tellija teenus) ligipääsu STAR toodangukeskkonna andmebaasile. 8.8.4. Teenuse täitja peab kindlustama Tellija andmehalduritele otseligipääsud STAR kõigi

keskkondade andmebaasidele. 8.8.5. Teenuse täitja peab pakkuma FTP (või samaväärne) serveri teenust, mille kaudu

edastab Tellija installeerimiseks vajalikud paketid. 8.9. Nõuded monoliit arhitektuuri tehnilisele ülesehitusele

8.9.1. STAR Toodangukeskkond: 8.9.2. Kasutatavad rakendusserverid peavad olema eraldatud andmebaasiserverist; 8.9.3. Rakendusserverid peavad võimaldama koormuse jaotamist vähemalt kahe serveri

vahel;

8.9.4. Igas rakendusserveris peab olema töösse rakendatud vähemalt kolm Java virtuaalserverit (JAVA Virtual Machine).

8.9.5. Keskkonnas peavad olema automaatse ümberlülitusega dubleerivad koormusjaoturid.

8.9.6. Koormusjaoturid peavad toetama lisaks koormuse jaotamisele ka SSL ühenduste termineerimist (SSL Offloading).

8.9.7. STAR toodangueelne- ja testkeskkond: 8.9.8. Toodangueelne keskkond (prelive) peab olema Toodangukeskkonnaga sarnase

konfiguratsiooniga, kuid võib olla ilma dubleeriva rakendusserverita. 8.9.9. Rakendusserveris peab olema töösse rakendatud vähemalt kolm Java

virtuaalserverit (JAVA Virtual Machine). 8.9.10. Test- ja koolituskeskkond võib olla ilma dubleeriva rakendusserverita ja vähendatud

Java virtuaalserverite arvuga. 8.9.11. Majutuskeskkond peab olema kaitstud automaatse ümberlülitusega dubleeritud

tulemüüriga; 8.10. Tellija tarkvara profiil STAR keskkondadele

8.10.1. Oracle Database 19g Standard Edition 8.10.2. Tellijal on olemas kahe (2) protsessori Oracle Standard Edition litsents koos toega. 8.10.3. Varukoopiate tarkvara valib Täitja teenuse nõuetest tulenevalt; 8.10.4. Toodangukeskkonna näidisarhitektuur on toodud punktis 11.

8.11. Litsentsid ja sertifikaadid 8.11.1. Serverite operatsioonisüsteemi tarkvarad peavad olema kaetud tootjapoolse

tarkvaratoega lepingu perioodi vältel. Vajalikud litsentsid tagab Täitja. 8.11.2. Infosüsteemi tööks vajalikud litsentsid ja tootja toe tagab Tellija; 8.11.3. Süsteemi arengust tingitud vajaduse korral tagab infosüsteemi tööks vajalikud

lisalitsentsid Tellija; 8.11.4. Turvalise ühenduse loomiseks vajalikud SSL sertifikaadid tagab Tellija; 8.11.5. Kõik keskkondade tööks vajalikud sertifikaadid ja nende kogused tuleb loetleda

Täitja poolt ja esitada Tellijale tööks vajalike sertifikaatide soetamiseks.

9. Nõuded mikroteenuste arhitektuuri tehnilisele ülesehitusele

9.1. Kubernetese klastrid eraldi toodangu-. toodangueelse ja testkeskkondade jaoks. 9.2. Testikeskkonna klastrit võib vajadusel kasutada ka arenduskeskkonnana. Samaaegselt on

testkeskkonna klastris STAR test ja arenduse rakendused. 9.3. Kubernetese klastreid peab saama laiendada lisaserveritega majutuse perioodi ajal; 9.4. Kubernetese klastri füüsilised serverid ei tohi olla jagatud teiste Teenuse täitja klientidega; 9.5. Soovituslik on kasutada Rancher Kubernetes Engine (RKE) Kubernetes distributsiooni; 9.6. Rancher kasutajaliides Kuberneteses rakenduste haldamiseks; 9.7. STAR rakendused Java ja JavaSckript keeltes; 9.8. PostgreSQL andmebaasid; 9.9. Redis andmebaasid; 9.10. RabbitMQ sõnumivahetus; 9.11. Minio S3 failisalvestus; 9.12. Matomo kasutajate käitumise monotooring; 9.13. Taristuteenused: 9.14. Kõrgkäideldav salvestusteenus klastri piires; 9.15. Sertifikaatide väljastus ja haldus (cert-manager); 9.16. Teenuseid kirjeldavad YAML failid paiknevad Tellija Gitlab lähtekoodi

repositooriumis; 9.17. Docker konteinerite registrid paikneb Tellija juures.

10. Toodangukeskkonna näitlik arhitektuur

IV. Lisad

1. Tehnilise kirjelduse lisad on:

1.1. Teenuse pass SKAIS1; 1.2. Teenuse pass SKAIS2; 1.3. Teenuse pass STAR; 1.4. TEHIK MFN 2024.

Lisa 2 - Hankelepingu projekt (1).pdf

Hankelepingu projekt

Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Pärnu mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm (edaspidi tellija), ja

Telia AS registrikood 10234957, aadress Mustamäe tee 3, 15033, Tallinn, keda esindab volikirja alusel Margus Danil (edaspidi täitja),

edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/4197-1 alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas:

1. Lepingu ese

1.1. Lepingu esemeks on tellimuse „Sotsiaalkindlustusameti infosüsteemide SKAIS ja STAR majutus- ja administreerimisteenus“ juures olevas tehnilises kirjelduses nimetatud tööd (edaspidi tööd).

1.2. Lepingu tööde maht on 14 kuud.

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

2.1. Täitja annab töö üle hiljemalt 14 kuud alates lepingu sõlmimisest. 2.2. Töö vahetulemused antakse üle igakuiselt kuu 7.ndaks kuupäevaks. Täitja esitab

tellija esindajale digitaalselt allkirjastatud aruande eelmise kuu tööde kohta, mis sisaldab loetelu teenusega seotud töödest ja tegevustest, süsteemi ressursside ja monitooringu näitajaid (kuised trendid serverite ja andmebaaside koormuse, võrguliikluse, vaba kettaruumi ja mälukasutuse kohta).

2.3. Ühekordsete, eraldi tellitud tööde kirjeldus sh nendele töödele kulunud aeg, näidatakse aruandes ja arvel eraldi reana.

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. Vajadusel esitab täitja tellijale soovitusi, märkuseid ja ettepanekuid teenuse

kvaliteedi parendamise või nõutud taseme säilitamiseks vajalike tegevuste kohta.

3. Lepingu hind

3.1. Tellija tasub lepingu alusel tellitud tööde eest kuutasudena kokku 889 058,94(kaheksasada kaheksakümmend üheksa tuhat viiskümmend kaheksa eurot ja üheksakümmend neli senti) eurot käibemaksuta.

3.2. Kuutasu jaguneb: 3.2.1. SKAIS1 kuutasu hind on 5 261,32 (viistuhat kakssada kuuskümmend üks

eurot ja kolmkümmend kaks senti) eurot käibemaksuta; 3.2.2. SKAIS2 kuutasu 47 342,89 (nelikümmend seitse tuhat kolmsada

nelikümmend kaks eurot ja kaheksakümmend üheksa senti) eurot käibemaksuta;

3.2.3. STAR kuutasu 9 200,00 (üheksa tuhat kakssada) eurot käibemaksuta; 3.2.4. Kubernetese workerite halduse kuutasu 1 700,00 (tuhat seitsesada) eurot

käibemaksuta; 3.3. Ühe töötunni hind on 75,00 (seitsekümmend viis) eurot käibemaksuta; Tasumine

toimub aruande alusel. Ühekordsete lisatööde vajadus kooskõlastatakse eelnevalt lepingu kontaktisikute vahel.

3.4. Täitja esitab tellijale e-arve pärast töö üleandmise-vastuvõtmise akti allkirjastamist.

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 Epp Laanepõld tel +372 7943 900, e-post

[email protected] või tema asendaja. 3.3. Täitja kontaktisikuks lepingu täitmisel on Minni Nool, e-post [email protected] või

tema asendaja.

4. Lõppsätted

4.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni.

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, mida ei allkirjastata koos lepinguga:

4.3.1. Lisa 1 - Tehniline kirjeldus; 4.3.2. TK Lisa 1 -Teenuse pass SKAIS1; 4.3.3. TK Lisa 2 – Teenuse pass SKAIS2; 4.3.4. TK Lisa 3 – Teenuse pass STAR; 4.3.5. Lisa 2 – Pakkumus;

5. Poolte allkirjad

Tellija: Täitja:

Sotsiaalkindlustusameti infosu_steemide ma...pdf

HANKIJA NIMI: Tervise ja Heaolu Infosüsteemide Keskus Pakkumusettepaneku nimetus: „Sotsiaalkindlustusameti infosüsteemide SKAIS ja STAR majutus- ja administreerimisteenus“ Käesolevaga teeb Tervise ja Heaolu Infosüsteemide Keskus (Hankija) Teile ettepaneku esitada pakkumus Sotsiaalkindlustusameti infosüsteemide SKAIS ja STAR majutus- ja administreerimisteenus teostamiseks raamlepingu nr 3-9/4197-1 alusel. Majutus- ja administreerimisteenuse hankeleping sõlmitakse tulenevalt vajadusest majutada ja administreerida sotsiaalkindlustusameti infosüsteeme SKAIS1, SKAIS2 ja STAR.

Pakkumused tuleb esitada hiljemalt 18.07.2025 kell 10:00 e-posti aadressile [email protected]. Pakkumus tuleb esitada eesti keeles ja digitaalselt allkirjastatult pakkuja poolt.

Pakkumus esitatakse Hankelepingu eseme tehnilises kirjelduses (lisa 1) toodud tööde teostamiseks. Alternatiivsete pakkumuste esitamine ei ole lubatav. Pakkumus peab olema jõus minimaalselt 30 päeva.

Pakkumusena tuleb esitada: Pakkumusena esitatakse kinnitus SKAIS1, SKAIS2 ja STAR-i majutus- ja administreerimisteenuse ning sellega seotud lisatööde pakkumise kohta 14-kuulisel perioodil alates 01.08.2025, järgides raamlepingus, selle lisades ning teenuse passides sätestatud tingimusi.

Raamlepingu alusel tellitakse lisatöid kuni 14-kuulisel perioodil. Töid teostatakse jooksva tunnihinna arvestuse põhiselt. Tööde ajaaruandes tuuakse välja tööde kirjeldused, pöördumiste ajad ning antakse ülevaadet serverite ressursside kasutusest aruandeperioodil.

Majutus- ja administreerimisteenuse osutamine ning sellega seotud lisatööd teostatakse raamlepingus sätestatud teenuste kuutasu ning lisatöö tunnihinna alusel. Pakkujal ei ole õigust nõuda täiendavat tasu või väljamakseid.

Küsimuste tekkimise korral palun võtke ühendust enne pakkumuse esitamise tähtaega aadressil [email protected]. Pakkumusettepanekuga koos edastatavad dokumendid:

Lisa 1. Hankelepingu eseme tehniline kirjeldus; Lisa 2. Hankelepingu projekt.

TK Lisa 1 - Teenuse pass SKAIS1.pdf

TK Lisa 1 - SKAIS1 (PKR) Teenuse pass

Teenuse pass: SKAIS1 teenuse majutuskeskkond

1. Tingimus Kokku lepitud tingimus

Serveriruum Kaks serveriruumi:

 Primaarne

 Sekundaarne

Serveriruum Serveriruumid peavad paiknema EV territooriumil. Serveriruumide minimaalne nõutud geograafiline vahemaa 1 km.

Serveriruumi standardile vastavus TIER3, mööndusega, et varugeneraator ei pea olema dubleeritud.

Serveriruumi standardile vastavus E-ITS H turbeaste

Teenuse pass: SKAIS1 Toodangukeskkond

Teenuse mahunäitajad

2 Tingimus Kokku lepitud tingimus

Maksimaalne tagatud üheaegsete sessioonide arv andmebaasis

500 sessiooni

Toodangu andmebaasi andmemahu kasv aastas 350GB

Varukoopiate tegemise minimaalne sagedus ja meetod

7 korda nädalas full backup. Varundus toimub öösel alates kell 00:01. Koopiat säilitatakse 7 päeva.

Üldmääratlus

3 Tingimus Kokku lepitud tingimus

Rakenduste tööaeg tööpäevadel (täiskoormusel) 8:00 - 17:00

E-ITS turvaklass K2T2S2

E-ITS turbeaste M

Planeeritud arendusmuudatuste arv kuus 1

Käideldavus

4 Tingimus Kokku lepitud tingimus

Hooldusaeg (katkestuseta) 22:00- 06:00

Planeeritud katkestusest etteteatamisaeg (vähemalt)

24 tundi

Ühe planeeritud katkestuse maksimaalne kestvus töövälisel ajal

4 tundi

Maksimaalne planeeritud katkestuste arv kuus Vastavalt kokkuleppele

Lubatud planeerimata katkestuste arv kuus 2

Andmekao riski põhjustada võiva erakorralise intsidendi korral teenuse lubatud summaarne seisak

4h nädalas, 8h kuus

Mõõtmisprotseduur Tõestatav monitooringu aruanne

Tehniline kasutajatugi (ITabi)

5 Tingimus Kokku lepitud tingimus

Suhtluskeel eesti

Telefonitugi 08:00 – 17:00

Kõnedele vastamine 95% 60 sek. jooksul

Üheaegsete kõnede arv -

e-mail 24/7/365

Pöördumiste registreerimine Automaatteavitus

Intsidentide teenustasemed

6 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, 24/7 90%-le reageeriti 0,5 tunni jooksul 100%-le reageeriti 2 tunni jooksul

Prioriteet: keskmine, tööpäevadel 8:00 - 17:00 90%-le reageeriti 2 tunni jooksul 100%-le reageeriti 1 tööpäeva jooksul

Prioriteet: madal, tööpäevadel 8:00 - 17:00 90%-le reageeriti 8 tunni jooksul 100%-le reageeriti 2 tööpäeva jooksul

Tellimuste teenustasemed

7 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, 24/7 100% vastavalt tähtajale

Prioriteet: keskmine, tööpäevadel 8:00 - 17:00 90% lahendati 3 kalendripäeva jooksul 100% lahendati 6 kalendripäeva jooksul

Prioriteet: madal, tööpäevadel 8:00 - 17:00 90% lahendati 5 kalendripäeva jooksul 100% lahendati 10 kalendripäeva jooksul

Teenuse pass: SKAIS1 Toodangueelne testkeskkond

Teenuse mahunäitajad

8 Tingimus Kokku lepitud tingimus

Maksimaalne tagatud üheaegsete sessioonide arv

100 sessiooni

Toodangueelse keskkonna andmebaasi andmemahu kasv aastas

350GB

Varukoopiate tegemise sagedus ja meetod Full backup kogu süsteemist - vajadusel.

Üldmääratlus

9 Tingimus Kokku lepitud tingimus

Tööaeg tööpäevadel 9:00- 17:00

E-ITS turvaklass K1T2S2

Arendusmuudatuste arv kuus Vajaduspõhine

Käideldavus

10 Tingimus Kokku lepitud tingimus

Hooldusaeg töövälisel ajal 17:00- 08:00

Planeeritud katkestusest etteteatamisaeg (vähemalt)

48 tundi

Ühe planeeritud katkestuse maksimaalne kestvus

Vajaduspõhine

Mõõtmisprotseduur -

Tehniline kasutajatugi (ITabi)

11 Tingimus Kokku lepitud tingimus

Suhtluskeel eesti

Telefonitugi -

Kõnedele vastamine -

Üheaegsete kõnede arv -

e-mail 24/7/365

Pöördumiste registreerimine Automaatteavitus

Intsidentide teenustasemed

12 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 8:00 - 17:00 -

Prioriteet: keskmine, tööpäevadel 8:00 - 17:00 -

Prioriteet: madal, tööpäevadel 8:00 - 17:00 -

Tellimuste teenustasemed

13 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 8:00 - 17:00 100% vastavalt tähtajale

Prioriteet: keskmine, tööpäevadel 8:00 - 17:00 90% lahendati 3 kalendripäeva jooksul 100% lahendati 6 kalendripäeva jooksul

Prioriteet: madal, tööpäevadel 8:00 - 17:00 90% lahendati 5 kalendripäeva jooksul 100% lahendati 10 kalendripäeva jooksul

Teenuse pass: SKAIS1 Testkeskkond

Teenuse mahunäitajad

14 Tingimus Kokku lepitud tingimus

Maksimaalne tagatud üheaegsete sessioonide arv

50 sessiooni

Testkeskkonna andmebaasi andmemahu kasv aastas

350GB

Varukoopiate tegemise sagedus ja meetod Vajaduspõhine

Üldmääratlus

15 Tingimus Kokku lepitud tingimus

Tööaeg tööpäevadel 9:00- 17:00

E-ITS turvaklass K1T1S1

Arendusmuudatuste arv kuus Vajaduspõhine

Käideldavus

16 Tingimus Kokku lepitud tingimus

Hooldusaeg töövälisel ajal Vajaduspõhine

Planeeritud katkestusest etteteatamisaeg (vähemalt)

24 tundi

Ühe planeeritud katkestuse maksimaalne kestvus

Vajaduspõhine

Lubatud maksimaalne planeerimata katkestuste summaarne kogukestvus nädalas

Vajaduspõhine

Mõõtmisprotseduur -

Tehniline kasutajatugi

17 Tingimus Kokku lepitud tingimus

Suhtluskeel eesti

Telefonitugi -

Kõnedele vastamine -

Üheaegsete kõnede arv -

e-mail 24/7/365

Pöördumiste registreerimine Automaatteavitus

Intsidentide teenustasemed

1.1.18 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 8:00 - 17:00 -

Prioriteet: keskmine, tööpäevadel 8:00 - 17:00 -

Prioriteet: madal, tööpäevadel 8:00 - 17:00 -

Tellimuste teenustasemed

1.1.19 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 8:00 - 17:00 100% vastavalt tähtajale

Prioriteet: keskmine, tööpäevadel 8:00 - 17:00 90% lahendati 3 kalendripäeva jooksul 100% lahendati 6 kalendripäeva jooksul

Prioriteet: madal, tööpäevadel 7:00 - 17:00 90% lahendati 5 kalendripäeva jooksul 100% lahendati 10 kalendripäeva jooksul

TK Lisa 2 - Teenuse pass SKAIS2.pdf

TK Lisa 2 - SKAIS2 Teenuse pass

Teenuse pass: SKAIS2 teenuse majutuskeskkond

1 Tingimus Kokku lepitud tingimus

Serveriruum Kaks serveriruumi:

 Primaarne

 Sekundaarne

Serveriruum Serveriruumid peavad paiknema EV territooriumil. Serveriruumide minimaalne nõutud geograafiline vahemaa 1 km.

Serveriruumi standardile vastavus TIER3, mööndusega, et varugeneraator ei pea olema dubleeritud.

Serveriruumi standardile vastavus E-ITS H turbeaste

Teenuse pass: SKAIS2 Toodangukeskkond

Teenuse mahunäitajad

2 Tingimus Kokku lepitud tingimus

Maksimaalne tagatud üheaegsete sessioonide arv Ametnike portaalis

500 sessiooni

Maksimaalne tagatud üheaegsete sessioonide arv Avalikus portaalis

5000 sessiooni

Teenuse pakkuja poolt tagatud SKAIS2 toodangu andmebaasi andmemahu kasv aastas

500GB

Minimaalne Pakkuja avalik interneti ühenduse kiirus

100 Mb/s

Andmete varukoopiaklass (RPO) RPO on 15 minutit

Varukoopiate tegemise minimaalne sagedus ja meetod

1 kord kuus full backup kogu süsteemist, 1 kord nädalas full backup kogu süsteemist, 6 korda nädalas incremental backup. Varundus toimub öösel alates kell 00:01

Arhiveerimine andmesaatkonda 1 kord kuus kopeeritakse kuu viimane varukoopia andmesaatkonda (krüpteeritult).

Üldmääratlus

3 Tingimus Kokku lepitud tingimus

Ametnike portaali tööaeg tööpäevadel (täiskoormusel)

7:00 - 19:00

Avalik portaali tööaeg tööpäevadel (täiskoormusel)

6:00 – 02:00

E-ITS turvaklass K2T2S2

E-ITS turbeaste M

Käideldavus

4 Tingimus Kokku lepitud tingimus

Hooldusaeg (katkestuseta) 22:00- 06:00

Planeeritud katkestusest etteteatamisaeg (vähemalt)

48 tundi

Ühe planeeritud katkestuse maksimaalne kestvus töövälisel ajal

4 tundi

Maksimaalne planeeritud katkestuste arv kuus Vastavalt kokkuleppele

Ametnike portaali lubatud summaarne seisak planeerimata katkestuse korral nädalas

kuni 2 tundi, kuid ühe katkestuse järjestikune ajaline pikkus ei tohi olla rohkem kui 30 minutit.

Avaliku portaali lubatud summaarne seisak planeerimata katkestuse korral nädalas

kuni 2 tundi, kuid ühe katkestuse järjestikune ajaline pikkus ei tohi olla rohkem kui 30 minutit.

Lubatud planeerimata katkestuste arv kuus Avalikus ja Ametnike portaalis

Andmekao riski põhjustada võiva erakorralise intsidendi korral teenuse lubatud summaarne seisak

4h nädalas, 6h kuus

Erakorralise intsidendi korral max taasteaeg (RTO)

RTO on 72 tundi

Mõõtmisprotseduur Pakkujapoolne tõestatav monitooringu aruanne

Tehniline kasutajatugi

5 Tingimus Kokku lepitud tingimus

Suhtluskeel eesti

Telefonitugi 24/7

Kõnedele vastamine 95% 60 sek. jooksul

Üheaegsete kõnede arv 3

e-mail või iseteenindus 24/7/365

Pöördumiste registreerimine Automaatteavitus

Intsidentide teenustasemed

6 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, 24/7 90%-le reageeriti 0,5 tunni jooksul 100%-le reageeriti 2 tunni jooksul

Prioriteet: keskmine, tööpäevadel 7:00 - 19:00 90%-le reageeriti 2 tunni jooksul 100%-le reageeriti 1 tööpäeva jooksul

Prioriteet: madal, tööpäevadel 7:00 - 19:00 90%-le reageeriti 8 tunni jooksul 100%-le reageeriti 2 tööpäeva jooksul

Tellimuste teenustasemed

7 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, 24/7 100% vastavalt tähtajale

Prioriteet: keskmine, tööpäevadel 7:00 - 19:00 90% lahendati 3 kalendripäeva jooksul 100% lahendati 6 kalendripäeva jooksul

Prioriteet: madal, tööpäevadel 7:00 - 19:00 90% lahendati 5 kalendripäeva jooksul 100% lahendati 10 kalendripäeva jooksul

Teenuse pass: SKAIS2 Toodangueelne keskkond

Teenuse mahunäitajad

8 Tingimus Kokku lepitud tingimus

Maksimaalne tagatud üheaegsete sessioonide arv Ametnike portaalis

100 sessiooni

Maksimaalne tagatud üheaegsete sessioonide arv Avalikus portaalis

100 sessiooni

Teenuse pakkuja poolt tagatud SKAIS2 toodangueelse keskkonna andmebaasi andmemahu kasv aastas

500GB

Maksimaalne lubatud säilitusmaht Piiramata

Pakkuja minimaalne interneti kiirus 100 Mb/s

Andmete varukoopiaklass (RPO) 1 nädal

Varukoopiate tegemise sagedus ja meetod 1 kord nädalas full backup kogu süsteemist

Üldmääratlus

9 Tingimus Kokku lepitud tingimus

Tööaeg tööpäevadel 9:00- 17:00

E-ITS turvaklass K1T2S2

Käideldavus

10 Tingimus Kokku lepitud tingimus

Hooldusaeg töövälisel ajal 19:00- 07:00

Planeeritud katkestusest etteteatamisaeg (vähemalt)

48 tundi

Ühe planeeritud katkestuse maksimaalne kestvus

24 tundi

Lubatud maksimaalne planeerimata katkestuste summaarne kogukestvus nädalas

24 tundi

Lubatud planeerimata katkestuste arv kuus Avalikus ja Ametnike portaalis

2 korda

Erakorralise intsidendi korral max taasteaeg (RTO)

RTO on 168 tundi

Mõõtmisprotseduur Pakkuja poolne tõestatav monitooringu aruanne tellija nõudmisel

Tehniline kasutajatugi

11 Tingimus Kokku lepitud tingimus

Suhtluskeel eesti

Telefonitugi 24/7

Kõnedele vastamine 95% 60 sek. jooksul

Üheaegsete kõnede arv 3

e-mail või iseteenindus 24/7/365

Pöördumiste registreerimine Automaatteavitus

Intsidentide teenustasemed

12 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 7:00 - 19:00 90%-le reageeriti 2 tunni jooksul 100%-le reageeriti 4 tunni jooksul

Prioriteet: keskmine, tööpäevadel 7:00 - 19:00 90%-le reageeriti 4 tunni jooksul 100%-le reageeriti 1 tööpäeva jooksul

Prioriteet: madal, tööpäevadel 7:00 - 19:00 90%-le reageeriti 8 tunni jooksul

100%-le reageeriti 2 tööpäeva jooksul

Tellimuste teenustasemed

13 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 7:00 - 19:00 100% vastavalt tähtajale

Prioriteet: keskmine, tööpäevadel 7:00 - 19:00 90% lahendati 3 kalendripäeva jooksul 100% lahendati 6 kalendripäeva jooksul

Prioriteet: madal, tööpäevadel 7:00 - 19:00 90% lahendati 5 kalendripäeva jooksul 100% lahendati 10 kalendripäeva jooksul

Teenuse pass: SKAIS2 Testkeskkond

Teenuse mahunäitajad

14 Tingimus Kokku lepitud tingimus

Maksimaalne tagatud üheaegsete sessioonide arv Ametnike portaalis

50 sessiooni

Maksimaalne tagatud üheaegsete sessioonide arv Avalikus portaalis

50 sessiooni

Teenuse pakkuja poolt tagatud SKAIS2 testkeskkonna andmebaasi andmemahu kasv aastas

500GB

Maksimaalne lubatud säilitusmaht Piiramata

Pakkuja minimaalne interneti kiirus 100 Mb/s

Andmete varukoopiaklass (RPO) 1 nädal

Varukoopiate tegemise sagedus ja meetod Enne igakordset süsteemi muudatust või tarnet. Varundus toimub öösel alates 00:01

Üldmääratlus

15 Tingimus Kokku lepitud tingimus

Tööaeg tööpäevadel 9:00- 17:00

E-ITS turvaklass K1T0S0

Käideldavus

16 Tingimus Kokku lepitud tingimus

Hooldusaeg töövälisel ajal 19:00- 07:00

Planeeritud katkestusest etteteatamisaeg (vähemalt)

24 tundi

Ühe planeeritud katkestuse maksimaalne kestvus

24 tundi

Lubatud maksimaalne planeerimata katkestuste summaarne kogukestvus nädalas

24 tundi

Lubatud planeerimata katkestuste arv kuus Avalikus ja Ametnike portaalis

2 korda

Erakorralise intsidendi korral max taasteaeg (RTO)

RTO on 168 tundi

Mõõtmisprotseduur Pakkuja poolne tõestatav monitooringu aruanne tellija nõudmisel

Tehniline kasutajatugi

17 Tingimus Kokku lepitud tingimus

Suhtluskeel eesti

Telefonitugi Tööpäevadel 8:00 – 19:00

Kõnedele vastamine 95% 60 sek. jooksul

Üheaegsete kõnede arv 3

e-mail või iseteenindus 24/7/365

Pöördumiste registreerimine Automaatteavitus

Intsidentide teenustasemed

18 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 7:00 - 19:00 90%-le reageeriti 2 tunni jooksul 100%-le reageeriti 4 tunni jooksul

Prioriteet: keskmine, tööpäevadel 7:00 - 19:00 90%-le reageeriti 4 tunni jooksul 100%-le reageeriti 1 tööpäeva jooksul

Prioriteet: madal, tööpäevadel 7:00 - 19:00 90%-le reageeriti 8 tunni jooksul 100%-le reageeriti 2 tööpäeva jooksul

Tellimuste teenustasemed

19 Tingimus Kokku lepitud tingimus

Prioriteet: kõrge, tööpäevadel 7:00 - 19:00 100% vastavalt tähtajale

Prioriteet: keskmine, tööpäevadel 7:00 - 19:00 90% lahendati 3 kalendripäeva jooksul 100% lahendati 6 kalendripäeva jooksul

Prioriteet: madal, tööpäevadel 7:00 - 19:00 90% lahendati 5 kalendripäeva jooksul 100% lahendati 10 kalendripäeva jooksul

TK Lisa 3 - Teenuse pass STAR 2204.pdf

Lisa 2 - STAR Teenuse pass

1. Teenuse pass: STAR Toodangukeskkond

Serveriruum Kaks serveriruumi

 Primaarne

 Sekundaarne

Serveriruum Serveriruumid peab paiknema EV territooriumil. Serveriruumide minimaalne nõutud geograafiline vahemaa 1km.

Serveriruumi standardile vastavus Serveriruum peab vastama E-ITS turvaklassi „H“ nõuetele.

Serveriruumi standardile vastavus TIER3, mööndusega, et varugeneraator ei pea olema dubleeritud.

1.1. Teenuse mahunäitajad

Jrk nr Tingimus Kokku lepitud tingimus

1.1.1. Maksimaalne lubatud üheaegne kasutajate/pöördumiste arv

800 kasutajat

1.1.2 Andmemaht majutusteenuse tsükli alguses ~3,5 TB

1.1.2. Maksimaalne prognoositav andmemahu kasv Juurdekasv aastas ~ 1 TB

1.1.3. Koormus 70 standardpäringut sekundis

1.1.4. Päringu kestus kohalikku andmebaasi Kuni 4 sek. 99,99%

1.1.5. Päringu kestus välisesse infosüsteemi Kuni 7 sek.

1.1.6. Maksimaalne lubatud säilitusmaht Piiramata

1.1.7. Minimaalne Pakkuja interneti ühendus 2 Gb/s

1.1.8. Andmete varukoopiaklass (RPO) RPO on 24 h

1.1.9. Varukoopiate tegemise sagedus ja meetod 1 kord nädalas full backup kogu süsteemist; 6 korda nädalas incremental backup (eelneva incremental backup-i suhtes) Varundus toimub öösel alates kell 00:01

1.2. Üldmääratlus

Jrk nr Tingimus Kokku lepitud tingimus

1.2.1. Tööaeg (täiskoormusel) 9:00- 17:00

1.2.2. Tööaeg pooltele kasutajate 8:00-9:00 ja 17:00-19:00

1.2.3. Massandmevahetuse tööaeg väliste registritega, andmeaita uute andmete edastamine

19:00-07:00

1.2.4. E-ITS turvaklass K2T2S2

1.2.5. E-ITS turbeaste M

1.2.6. Planeeritud arendusmuudatuste tarnete arv kuus 8

1.3. Käideldavus

Jrk nr Tingimus Kokku lepitud tingimus

1.3.1. Hooldusaeg (katkestuseta) 22:00- 06:00

1.3.2. Planeeritud katkestusest etteteatamisaeg (vähemalt)

48 tundi

1.3.3. Ühe planeeritud katkestuse maksimaalne kestvus töövälisel ajal

4 tundi

1.3.4. Maksimaalne planeeritud katkestuste arv kuus Vastavalt kokkuleppele

1.3.5. Lubatud summaarne seisak planeerimata katkestuse korral nädalas

Kuni 2 tundi

1.3.6. Lubatud planeerimata katkestuste arv kuus 2

1.3.7. Mõõtmisprotseduur Pakkujapoolne tõestatav monitooringu aruanne

1.4. Tehniline kasutajatugi

Jrk nr Tingimus Kokku lepitud tingimus

1.4.1. Suhtluskeel eesti

1.4.2. Telefonitugi Tööaeg

1.4.3. Kõnedele vastamine 60 sek jooksul, 95%

1.4.4. Üheaegsete kõnede arv 3

1.4.5. e-mail või iseteenindus 24/7/365

1.4.6. Pöördumiste registreerimine Automaatteavitus

1.4.7. Pöördumisele reageerimisaeg ( peab olema täidetud punktis 1.3.7 summaarne seisak nädalas 2 h)

2 h jooksul, Tööaeg

2. Teenuse pass: STAR Test- ja koolituskeskkond

2.1. Teenuse mahunäitajad

Jrk Tingimus Kokku lepitud tingimus

2.1.1. Maksimaalne lubatud (üheaegne kasutajate) pöördumiste arv

Kuni 100 kasutajat

2.1.2. Maksimaalne prognoositav andmemaht Andmet mahu kasv kuni 10GB

2.1.3. Koormus 30 standardpäringut sekundis

2.1.4. Päringu kestus kohalikku andmebaasi Kuni 7 sek 99,99%

2.1.5. Päringu kestus välisesse infosüsteemi Kuni 10 sek

2.1.6. Maksimaalne lubatud säilitusmaht Piiramata

2.1.7. Pakkuja minimaalne interneti kiirus 2 Gb/s

2.1.8. Andmete varukoopiaklass (RPO) 1 nädal

2.2. Üldmääratlus

Jrk nr Tingimus Kokku lepitud tingimus

2.2.1. Tööaeg tööpäevadel 9:00- 17:00

2.2.2. E-ITS turvaklass K1T0S0

2.2.3. Planeeritud arendusmuudatuste tarnete arv kuus 20

2.3. Käideldavus

Jrk nr Tingimus Kokku lepitud tingimus

2.3.1. Hooldusaeg töövälisel ajal 19:00- 07:00

2.3.2. Planeeritud katkestusest etteteatamisaeg (vähemalt)

48 tundi

2.3.3. Ühe planeeritud katkestuse maksimaalne kestvus

24 tundi

2.3.4. Lubatud maksimaalne planeerimata katkestuste summaarne kogukestvus nädalas

24 tundi

2.3.5 Mõõtmisprotseduur Pakkuja poolne tõestatav monitooringu aruanne tellija nõudmisel

2.4. Tehniline kasutajatugi

2.4.1. Suhtluskeel eesti

2.4.2. Telefonitugi Tööaeg

2.4.3. Kõnedele vastamine 60 sek jooksul, 95%

2.4.4. Üheaegsete kõnede arv 3

2.4.5. E-mail ja/või iseteenindus 24/7/365

2.4.6. Pöördumiste registreerimine Automaatteavitus

2.4.7. Pöördumisele reageerimisaeg 2 h jooksul, Tööaeg

3. Teenuse pass: STAR Statistikakeskkond

3.1. Teenuse mahunäitajad

Jrk Tingimus Kokku lepitud tingimus

3.1.1. Maksimaalne lubatud (üheaegne kasutajate) pöördumiste arv

3.1.2. Maksimaalne prognoositav andmemaht Andmete mahu kasv kuni 80 GB

3.2. Üldmääratlus

Jrk nr Tingimus Kokku lepitud tingimus

3.2.1. Tööaeg 9:00- 17:00

3.2.2. E-ITS turvaklass K1T2S2

3.3. Käideldavus

Jrk nr Tingimus Kokku lepitud tingimus

3.3.1. Hooldusaeg (katkestuseta) 19:00- 07:00

3.3.2. Planeeritud katkestusest etteteatamisaeg (vähemalt)

24 tundi

3.3.3. Ühe planeeritud katkestuse maksimaalne kestvus

24 tundi

3.3.4. Lubatud maksimaalne planeerimata katkestuste summaarne kogukestvus nädalas

24 tundi

3.4. Tehniline kasutajatugi

3.4.1. Suhtluskeel eesti

3.4.2. Telefonitugi Tööaeg

3.4.3. Kõnedele vastamine 60 sek jooksul, 95%

3.4.4. Üheaegsete kõnede arv 3

3.4.5. E-mail ja/või iseteenindus 24/7/365

3.4.6. Pöördumiste registreerimine Automaatteavitus

3.4.7. Pöördumisele reageerimisaeg 2 h jooksul, Tööaeg

4. Teenuse pass: Toodangueelne keskkond

4.1. Teenuse mahunäitajad

Jrk Tingimus Kokku lepitud tingimus

4.1.1. Maksimaalne lubatud (üheaegne kasutajate) pöördumiste arv

Kuni 20 kasutajat

4.1.2. Maksimaalne prognoositav andmemaht Stardimaht 3,5TB ja juurdekasv aastas kuni 1TB

4.1.3. Koormus 30 standardpäringut sekundis

4.1.4. Päringu kestus kohalikku andmebaasi Kuni 7 sek 99,99%

4.1.5. Päringu kestus välisesse infosüsteemi Kuni 10 sek

4.1.6. Maksimaalne lubatud säilitusmaht Piiramata

4.1.7. Pakkuja minimaalne interneti kiirus 2 Gb/s

4.1.8. Andmete varukoopiaklass (RPO) 1 nädal

4.1.9. Varukoopiate tegemise sagedus ja meetod 1 kord nädalas full backup kogu süsteemist

4.2. Üldmääratlus

Jrk nr Tingimus Kokku lepitud tingimus

4.2.1. Tööaeg 9:00- 17:00

4.2.2. E-ITS turvaklass K1T1S2

4.2.3. Planeeritud arendusmuudatuste tarnete arv kuus

4.3. Käideldavus

Jrk nr Tingimus Kokku lepitud tingimus

4.3.1. Hooldusaeg töövälisel ajal 19:00- 07:00

4.3.2. Planeeritud katkestusest etteteatamisaeg (vähemalt)

48 tundi

4.3.3. Ühe planeeritud katkestuse maksimaalne kestvus

24 tundi

4.3.4. Lubatud maksimaalne planeerimata katkestuste summaarne kogukestvus nädalas

24 tundi

4.3.5. Lubatud planeerimata katkestuste arv kuus 2 korda

4.3.6 Mõõtmisprotseduur Pakkuja poolne tõestatav monitooringu aruanne tellija nõudmisel

4.4. Tehniline kasutajatugi

4.4.1. Suhtluskeel Eesti

4.4.2. Telefonitugi Tööaeg

4.4.3. Kõnedele vastamine 60 sek jooksul, 95%

4.4.4. Üheaegsete kõnede arv 3

4.4.5. E-mail ja/või iseteenindus 24/7/365

4.4.6. Pöördumiste registreerimine Automaatteavitus

4.4.7. Pöördumisele reageerimisaeg 2 h jooksul, Tööaeg

5. Mõisted

5.1. Tööaeg - tööaeg on ajavahemik, millal teenus on kasutajatele kättesaadav.

Massandmevahetuse tööaeg. Massandmevahetuse tööaeg väliste registritega, andmeaita

uute andmete edastamine.

5.2. Standardpäring - kasutaja poolne tegevus/päring infosüsteemi kasutamiseks veebilehitseja

kaudu.

5.3. Teenuse raport - monitooringusüsteemi põhine sõnaline aruanne tellija esindajale, mis

sisaldab vähemalt järgmisi osiseid või peatükke:

5.3.1. perioodi jooksul registreeritud intsidendid;

5.3.2. tehtud süsteemiuuendused (sh tarkvara kui ka riistvara);

5.3.3. süsteemi jõudluse ja mahu monitooringunäitajad;

5.3.4. andmebaasistatistika (päringute arv, kestvus, SLA ületused);

5.3.5. andmebaasi mahu kasv võrreldes eelneva perioodiga ning üldmaht;

5.3.6. kokkuvõte varasematest intsidentidest, rakendatud meetmetest ja soovitused;

5.3.7. tellija pöördumiste arv ja pöördumise sisu.

5.4. Hooldusaeg - hooldussaeg on kokku lepitud tööajast üle jääv ajavahemik hooldustöödeks,

mille jooksul teenus võib, kuid ei pruugi olla kättesaadav.

5.5. Maksimaalne lubatud üheaegne kasutajate arv - maksimaalne lubatud üheaegne

kasutajate arv on teenust üheaegselt kasutavate kasutajate arv, mille korral on tagatud

teenuse kvaliteetne toimimine.

5.6. Planeeritud katkestus - planeeritud katkestus on eelnevalt kokkulepitud ajavahemik, mille

jooksul teenus ei ole kättesaadav. Planeeritud katkestused toimuvad ainult töövälisel ajal.

5.7. Planeerimata katkestus - planeerimata katkestus on tööajal aset leidev mitte plaanipärane

katkestus teenuse toimimises. Planeerimata katkestuseks ei loeta olukorda, kus on häiritud

vähese arvu kasutajate töö, kuid asutuses (sama hoone piires) on teenus kättesaadav.

Planeerimata katkestus algab kui tööajal mingi teenus või funktsionaalsus ei toimi.

Planeerimata katkestus lõppeb kui kõik teenused ja funktsioonid on taastatud.

5.8. Lubatud planeerimata katkestuse kogukestvus - lubatud planeerimata katkestuse

kogukestvus on maksimaalne lubatud planeerimata katkestuste kestvus mingil ajaperioodil.

5.9. Kriitilisuse klass - kriitilisuse klass on teenustaseme taastamise maksimaalne ajakulu ning

prioriteet mis järjekorras katastroofilises olukorras teenused taastatakse.

5.10. Lisatöö - tellija poolt tellitud ülesanded, mis ei kuulu hankeobjektiks oleva teenuse

hulka: ühekordsed tööd ja teenus.

TK Lisa 4 - TEHIK MFN 2024.pdf

Versioon: 2.3

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

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

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

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

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

Nõude nr

Nõude sisu Seletused Digiriigi CFR

Iseteenindus Veebid Karbitoode Koostamise eest vastutaja

Testimise läbi viib või kinnitab

1. Vastavus üldistele standarditele

1.1 Lahendus loomisel peab arvestama digiriigi ristfunktsionaalsed nõudeid.

Kohustus- ja ootustasemel olevad nõuded tuleb rakendada.

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

Erisused tuleb kokku leppida Tellija lahenduse arhitektiga.

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

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

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

1.3 Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile.

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

V V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

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

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

Testija

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

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

Arhitekt

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

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

CFR selgitus: WCAG 2.2 alates 05.10.2023

#39 V V V Arendaja Testija

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

Valideerimiseks kasutatakse vastavaid validaatoreid:

https://validator.w3.org/

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

#38 V V Arendaja Testija

1.8 Allkirjastamisel tuleb kasutada Tellija SiGA/SiVa vahendusteenust.

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

Arhitekt

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

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

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

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

#10

V V V Arendaja Turvatestija

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

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

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

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

#46 V V V Arendaja Arhitekt

Administraator

Turvatestija

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

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

V V V Arendaja Turvatestija

Arhitekt

Autentimise mehhanism tuleb kokku leppida Tellijapoolse arhitektiga.

1.12 Infosüsteem peab kasutama serveri kellaaega.

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

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

#51 V V V Arendaja Arhitekt

Administraator

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

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

V V V Arendaja Arhitekt

Testija

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

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

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

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

https://microservices.io/

#21 V V Arendaja Arhitekt

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

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

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

https://veera.eesti.ee/

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

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

#36 V V Arendaja Arhitekt

1.17 Lahenduse loomisel peab arvestama riiklikku koostoimeraamistikuga.

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

Administraator

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

Liidestatakse Maa-ameti ADS teenusega.

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

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

#53 V V Arendaja Arhitekt

Standardija

Testija

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

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

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

#54 V V Arendaja Standardija

Testija

2. Nõuded rakenduse arhitektuurile

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

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

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

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

#7 V V V Arendaja Arhitekt

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

V V V Arendaja Administraator

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

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

V V V Arendaja Administraator

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

Lahenduses ei tohi olla sisse kompileeritud absoluutseid URI-sid.

V V V Arendaja Administraator

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

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

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

V V V Arendaja Administraator

Testija

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

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

Tavaline käivitusaeg ei tohi ületada 30 sekundit.

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

V V V Arendaja Testija

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

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

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

Näiteks:

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

V V Arendaja Arhitekt

Testija

Administraator

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

#50 V V V Arendaja Administraator

Testija

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

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

V V Arendaja Administraator

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

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

V V Arendaja Arhitekt

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

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

V V Arendaja Arhitekt

2.12 Tuleb kasutada päringumuutujaid (Parameter Binding).

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

V V Arendaja Arhitekt

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

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

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

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

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

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

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

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

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

V V Arendaja Administraator

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

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

Näiteks objektide talletuseks kasutada objektide talletamise lahendust.

V V Arendaja Arhitekt

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

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

V V V Arendaja Testija

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

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

V V Arendaja Arhitekt

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

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

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

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

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

V V V Arendaja Administraator

2.21 Konfiguratsiooniparameetrite nimed peavad olema sisulised. Kui see ei ole

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

V V Arendaja Administraator

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

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

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

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

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

#23

#29

#64

V V Arendaja Arhitekt

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

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

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

V V V Arendaja Administraator

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

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

V V V Arendaja Administraator

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

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

V V Arendaja Administraator

Testija

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

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

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

V V V Arendaja Administraator

2.27 Keskkonnapõhised muutujad peavad olema konfiguratsiooniparameetritega seadistatavad.

Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele.

V V V Arendaja Administraator

Testija

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

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

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

#30 V V V Arendaja Arhitekt

Testija

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

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

V V Arendaja Arhitekt

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

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

V V V Arendaja Administraator

Testija

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

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

complexType defineerimisel tuleb sellele lisada any element.

V V V Arendaja Arhitekt

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

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

V V V Arendaja Administraator

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

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

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

V V V Arendaja Administraator

Testija

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

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

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

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

V V V Arendaja Testija

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

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

V V Arendaja Administraator

Testija

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

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

V V V Arendaja Arhitekt

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

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

V V V Arendaja Arhitekt

2.38 Rakenduse uuendustega kaasnevad andmebaasi muudatused tuleb automatiseerida ja versioneerida.

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

2.39 Mitterelatsioonilises mudelis andmete hoiustamine tuleb eraldi kokkuleppida.

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

V V V Arendaja Arhitekt

2.40 Mikroteenuste arhitektuuris vältida ebavajalikku andmete dubleerimist.

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

V Arendaja Arhitekt

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

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

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

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

#22 V V V Arendaja Arhitekt

3. Turvalisuse tagamisega seotud nõuded

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

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

Täpsem tehniline lahendus leida koos TEHIKu poolse arhitektiga.

V V V Arendaja Turvatestija

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

V V V Arendaja Turvatestija

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

V V Arendaja Turvatestija

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

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

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

Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni;

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

Täpne realisatsioon tuleb kokku leppida Tellija arhitektiga.

#55

#49

V V Arendaja Turvatestija

Arhitekt

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

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

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

V Arendaja Arhitekt

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

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

Üldjoones on kõik keskkonnad majutatud Tellija majutuses.

V V V Arendaja Turvatestija

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

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

V V V Arendaja Turvatestija

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

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

V V V Arendaja Turvatestija

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

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

V V V Administraator Turvatestija

kaitsmaks rakendust lubamatute päringute eest.

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

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

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

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

V V V Arendaja Turvatestija

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

Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega.

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

V V V Arendaja Turvatestija

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

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

V V Arendaja Turvatestija

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

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

#30 V V V Arendaja Turvatestija

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

V V V Arendaja Turvatestija

3.15 Arendus peab olema orienteeritud toodangukeskkonnas toimimiseks.

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

V V V Arendaja Turvatestija

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

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

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

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

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

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

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

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

V V V Arendaja Turvatestija

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

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

V V V Arendaja Turvatestija

3.20 Lahendus peab olema kaitstud HTMLi süstimiste eest.

OWASP soovitab kasutada DOMPurify lahendust HTMLi saneerimiseks

#44 V V V Arendaja Arhitekt Turvatestija

4. Logimine

4.1 Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses.

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

V V V Arendaja Arhitekt

Administrator

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

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

V V V Arendaja Arhitekt

Administraator

Testija

4.3 Logisündmused peavad olema loogiliselt eristatavad.

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

#41 V V V Arendaja Arhitekt

Administraator

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

V V V Arendaja Arhitekt

Testija

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

V V Arendaja Administraator

Testija

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

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

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

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

V V Arendaja Arhitekt Infoturbespetsialist

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

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

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

V V V Arendaja Arhitekt

Testija

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

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

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

#17 V V V Arendaja Arhitekt

Testija

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

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

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

V V V Arendaja Testija

Turvatestija

Infoturbespetsialist

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

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

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

V V V Arendaja

Administraator

Infoturbespetsialist

Testija

4.12 Süsteemsed logid ei tohi sisaldada otseseid isikuandmeid.

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

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

Konkreetne detailsus ja tehniline lahendus tuleb kokkuleppida Tellija arhitektiga.

V V V Arendaja Arhitekt

Testija

Turvatestija

Infoturbespetsialist

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

Näiteks NULL V V Arendaja Testija

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

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

V V Arendaja Testija

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

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

V V V Arendaja Administraator

Testija

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

V V V Arendaja Administraator

Testija

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

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

V V V Arendaja Arhitekt

Administraator

Infoturbespetsialist

5. Testimine

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

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

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

#12 V V V Arendaja Testija

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

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

#12

#35

V Arendaja Arhitekt

Testija

5.3 Lahendus peab olema minimaalselt 50% ulatuses kaetud automaatsete

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

#12

#33

V Arendaja Arhitekt

Testija

vastuvõtutestidega.

5.4 Rakendusega peab olema kaasas skript jõudlustestide tegemiseks.

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

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

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

#12

#34

V V Arendaja Arhitekt

Administraator

Testija

5.5 Testimine toodangu andmetega on keelatud.

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

V V Arendaja Arhitekt

Administraator

Testija

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

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

Parendused ja lahendused tuleb kokku leppida Tellija arhitektiga.

#10

V V Arendaja Arhitekt

Administraator

Testija

6. Monitooring

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

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

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

#16 V V Arendaja Arhitekt

Administraator

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

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

#16 V Arendaja Arhitekt

Administraator

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

Tuleb rakendada OpenMetrics spetsifikatsiooni.

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

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

https://openmetrics.io/

#16 V V Arendaja Arhitekt

Administraator

7. Nõuded rakenduse lähtekoodile

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

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

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

#2 V V Arendaja Arhitekt

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

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

Rakendama peab dokumenteerimisel programmeerimiskeele parimaid praktikaid.

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

#2 V V Arendaja Arhitekt

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

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

Näiteks muutujate nimed peavad olema selged ja arusaadavad.

Hea näide muutujast: elapsedTimeInDays

Halb näide muutujast: etid

#2 V V Arendaja Arhitekt

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

Nt Javas identifikaator --> ID V V Arendaja Arhitekt

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

V V Arendaja Arhitekt

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

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

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

V V Arendaja Arhitekt

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

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

V V Arendaja Arhitekt

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

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

V V Arendaja Arhitekt

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

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

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

V Arendaja Arhitekt

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

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

IT profiil: Lähtekoodi analüüs

#10

#40

V V Arendaja Arhitekt

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

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

V V Arendaja Arhitekt

7.12 Arendamisel kasutatakse DRY ja SOLID printsiipe.

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

V V Arendaja Arhitekt

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

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

#28

#63

V V Arendaja Arhitekt

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

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

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

#10 V V Arendaja Arhitekt

7.15 Üleantava lahendusega peab olema kaasas viis SBOM genereerimiseks.

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

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

https://www.sbom.com/

V V Arendaja Arhitekt

7.16 Tehniliste komponentide API'del eksisteerib automaatselt genereeritud dokumentatsioon.

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

https://www.openapis.org/

#20 V Arendaja Arhitekt

8. Andmekvaliteet

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

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

Testija

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

V V Arendaja Arhitekt

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

Välja arvatud logimisvormi lahtrid autentimisel.

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

V V Arendaja Testija

8.4 Lahenduses peab olema tagatud idempotentsus.

Kasutaja sama tegevuse kordamisel ei tohi tekkida lahendusse andmeid topelt.

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

V V Arendaja Arhitekt

Testija

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

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

#58 V Arendaja Arhitekt

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

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

#58 V Arendaja Arhitekt

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

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

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

#58 V Arendaja Arhitekt

9. Kasutajaliides

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

V V V Arendaja Projektijuht

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

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

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

V V V Arendaja Testija

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

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

V V Arendaja Testija

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

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

V V V Arendaja Testija

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

Toetatud peavad olema töökohaprofiilis loetletud resolutsioonid.

Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba.

V V Arendaja Testija

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

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

V V Arendaja Testija

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

V V V Arendaja Testija

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

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

V V V Arendaja Testija

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

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

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V Arendaja Testija

9.10 Rakenduse kasutajaliides peab teavitama kasutajat ette sessiooni aegumisest.

Etteteavitamise aeg peab olema konfigureeritav. V V V Arendaja Administraator

Testija

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

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

V V Arendaja Testija

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

V V Arendaja Testija

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

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

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

V V Arendaja Testija

10. Dokumentatsioon

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

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

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Infoturbe spetsialist

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

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

#57 V Arendaja

Projektijuht

Tellija RIHA haldur

Projektijuht

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

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

V V Arendaja Projektijuht

Arhitekt

Administraator

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

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

Testija

Infoturbe spetsialist

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

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

V V Arendaja Projektijuht

Arhitekt

Administraator

Infoturbe spetsialist

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

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

V V V Arendaja Projektijuht

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

V V Aremdaja Arhitekt

Administraator

11. Versioonihaldus

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

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

#1 V V Arendaja Arhitekt

Administraator

11.2 Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi.

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

V V Arendaja Arhitekt

Administraator

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

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

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

V V Arendaja Projektijuht

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

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

12. Paigalduspaketi kooste

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

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

Versiooni suurt numbrit A kasutatakse ka API versiooni defineerimiseks.

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

https://semver.org/

#15 V Arendaja Arhitekt

Administraator

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

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

V V Arendaja Administraator

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

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

Eelistatud on kasutada Dockerfile ja Gitlab töövooge.

V V Arendaja Projektijuht

Administraator

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

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

V V Arendaja Arhitekt

Administraator

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

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

V V Arendaja Administraator

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

#4 V V Arendaja Arhitekt

12.7 Andmebaasi paigalduse skriptid ei tohi olla kompileeritud.

Administraator tahab veenduda skripti sisus. V V Arendaja Administraator

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

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

V V Arendaja Arhitekt

12.9 Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse lokaalselt

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

V V Arendaja Arhitekt

mõnes konteinerlahenduses (Docker) käivitamiseks.

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

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

#13 V V Arendaja Arhitekt

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

https://helm.sh/

Helmi jaoks kasutatava malli annab Tellijapoolne arhitekt.

V V Arendaja

Arhitekt

Arhitekt

Administraator

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

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

V V Arendaja

Arhitekt

Arhitekt

Administraator

Seosed

Nimi	K.p.	Δ	Viit	Tüüp	Org	Osapooled
pakkumus	21.07.2025	1	3-9/4653-1 🔒	Sissetulev kiri	tehik	Telia Eesti AS
Leping	22.07.2024	365	3-9/4197-2 🔒	Riigihankeleping	tehik
Leping	21.06.2024	396	3-9/4197-1	Riigihankeleping	tehik