Leping

Tehniline kirjeldus
Tervisejuhtimise töölaud – GOVSSO testimine

1 Tellimuse kirjeldus 1
2 Testitava süsteemi kirjeldus 1
3 Teenuse kirjeldus 3
4 Töö tulemid ja tähtajad 3

1 Tellimuse kirjeldus
1.1 Tellimuse esemeks on Tervisejuhtimise töölaual implementeeritud GOVSSO lahenduse turvalisuse testimine OWASP (Open Web Application Security Project) ASVS (Application Security Verification Standard Project) versioon 3.0.1 (või juhul kui sõlmitava raamlepingu kehtivuse perioodil peaks eksisteerima uuem versioon, siis uuemale) tasemetele 3 vastavate turvatestide teostamine.
2 Testitava süsteemi kirjeldus

2.1 Tervisejuhtimise töölaud (TJT) on upTIS põhimõtetest lähtuv andmete haldamise tööriist ja keskne töövahend kõigile terviseandmeid vajavatele spetsialistidele.
2.1.1 TJT on ette nähtud abivahendina nende olemasolevate tööprogrammide kõrvale, pakkudes uuenduslikke funktsioone, mida neil oma infosüsteemides ei ole.
2.1.2 Neile, kel pole oma tööprogrammi, saavad TJT abil teha kõike, mida patsiendi käsitlemiseks on vaja.
2.1.3 Lahenduse peamine eesmärk on spetsialistide toomine ühtsesse infovälja, võimaldades neil terviseandmeid struktuurselt sisestada ja kuvada ning omavahel vahetada.
2.1.4 Spetsialistidele tekib terviklik ülevaade patsiendi terviseandmetest, võimalus neid struktureeritult dokumenteerida ning kasutada patsiendi käsitlust toetavaid digilahenduse ühes kohas.
2.2 TJT on ühe patsiendi tervisekäsitluse töövahend.
2.2.1 Esialgu ei ole TJT skoop planeeritud töövoo haldamise lahendust (registratuur, patsiendi nimekirjad, vastuvõtugraafikud jms) ega aruandluse lahendust (raviarved, laohaldus, labori toimingud jms).
2.2.2 See tähendab, et lahendus on asjakohane sellest hetkest, kui patsient oma infosüsteemis lahti võtta.
2.2.3 Kellel pole parajasti infosüsteemi, saab muidugi end autentida ja patsiendi isikuandmeid sisestades infole ligi.
2.3 TJT on arendatud GOVSSO sisselogimise võimalus, mille eesmärgiks on võimaldada TTOde süsteemidest, kus on ka GOVSSO juurutatud, siseneda TJTsse ilma täiendavat autentimist tegemata.
2.3.1 Kogu suhtlus GOVSSO-ga toimub läbi oauth-gateway (oauth-bff muster) backend teenuse.
2.3.2 Frontendi paistab välja ainult oauth-gateway poolt loodud cookie sessiooni identifikaatoriga.
2.3.3 Küsides andmeid TJT backend teenustest, teeb frontend päringu oauth-gateway poole koos sessiooni cookie-ga. oauth-gateway vahetab sessiooni cookie GOV SSO access tokeni vastu ning edastab päringu TJT backend teenustesse.
2.3.4 Kõik TJT backend teenused valideerivad access tokeni valiidsust, kontrollides kehtivust ja sertifikaati (samamoodi nagu praeguse TEHIK SSO lahenduse puhul).
2.3.5 Kui kasutaja on varasemalt TTO süsteemis GOV SSO-ga sisse loginud, siis TJT-d avades suunatakse kasutaja GOV SSO lehele, kus tuvastatakse kehtiv sessioon ja suunatakse tagasi oauth-gateway teenusesse, kus salvestatakse access ja refresh tokenid cache-i ning genereeritakse sessiooni cookie.
2.3.6 Kasutajate väljalogimine (k.a back channel logout) toimub läbi oauth-gateway, mille käigus kustutakse antud kasutajate andmed (access token, session, id token, refresh token), mis keelab TJT edasist kasutamist.
2.4 Arhitektuur
2.5 Info arhitektuuri kohta - https://wiki.sm.ee/spaces/TJT/pages/221496170/Dokumentatsioon+Arhitektuur+ja+tehniline+lahendus
2.6 Funktsionaalsus ja testimise skoop
2.6.1 GOVSSO ja OAuth BFF lahendus, mille spetsifikatsioon on kirjeldatud siin - https://wiki.sm.ee/spaces/TJT/pages/334073535/GovSSO+ja+OAuth+BFF+lahendus

3 Teenuse kirjeldus
3.1. Tellimuse eesmärgiks on tellija poolt tellitavate, olemasolevate ja valitud infosüsteemide turvalisuse testimine OWASP (Open Web Application Security Project) ASVS (Application Security Verification Standard) versioon 3.0.1 (või juhul kui sõlmitava raamlepingu kehtivuse perioodil peaks eksisteerima uuem versioon, siis uuemale) tasemetele 2 ja 3 vastavate turvatestide teostamine.
3.2. Turvatestimise käigus tuleb metoodiliselt testida ja hinnata kõiki potentsiaalseid turvavigu (sealhulgas OWASP Top Ten) ning need tuleb testiraportis detailselt välja tuua koos võimalike lahenduste ja soovitustega, st leitud vigade puhul välja tuua võimalikud ohustsenaariumid.
3.3. Testimisel tuleb kontrollida, et testitavate infosüsteemide võimalike haavatavuste kaudu ei oleks võimalik juurde pääseda andmetele, mis asuvad väljaspool testitava rakenduse funktsionaalsust. Testimine hõlmab ka kasutajate horisontaalset ja vertikaalset õiguste ületamise turvatestimist.
3.4. Kõik testimised ja lähtekoodi kontrollid tuleb teostada ka käsitsi, sest testitavad süsteemid ei pruugi automaatsete vahenditega testimisel tõepäraseid tulemusi anda. Testimise lõppedes edastab täitja testitavate toodete/lahenduste testiraportid, krüpteerituna tellijale.
3.5. Turvatestimised viiakse läbi arendus- või testkeskkondades, kui ei ole kokku lepitud teisiti. Vajadusel luuakse tellija ja testija süsteemide vahele turvatud kanal infosüsteemidele ligipääsemiseks.
3.6. Testimise läbiviimiseks peab täitja esitama tellijale IP aadressid, millelt hakatakse turvateste läbi viima. Tellija avab ligipääsu vastavatelt IP aadressidelt testitavatele süsteemidele. Vajadusel teeb tellija ka vajalikud testkasutajad.
3.7. Lõppraport tuleb vormistada vastavalt OWASP ASVS reeglitele.
4 Töö tulemid ja tähtajad
4.1. Tööd on teostatud ja dokumenteeritud vastavalt nõuetele, vt. 3 Teenuse kirjeldus.
4.2. Rakenduse veebiliideses ei ole üldtuntud turvaauke, mis võimaldaksid välisel ründajal rakendusse sisse murda ja teha selles volitamata tegevusi.
4.3. Täitja ja tellija on tugisüsteemina kasutanud tellija kasutuses olevat projektihaldustarkvara vastavalt kokkulepetele.
4.4. Täitja on täitnud tööaja arvestust.
4.5. Turvatestimine toimub I etapis peale eeltegevuste teostamist.
4.5.1. Turvastestimise tööde tähtaeg on 2.05.2025 .
4.5.2. Turvatestimine viiakse läbi alates 7.04.2025 ning kestab kuni 2.05.2025 (kestus).
4.5.2.1. Lõplik turvatestimise periood lepingu sõlmimisest on kuni 8 töönädalat, misjärel akteeritakse tehtud tööd.
4.5.2.2. Turvatestimisele järgneb tuvastatud vigade paranduste teostamine tellija poolt, mille järel peab täitja teostama parandustele üle testimise kuni 1,5 kuu jooksul, misjärel akteeritakse tehtud tööd.
4.5.2.3. Juhul, kui hankelepingut ei sõlmita enne 7.04.205, siis lükkub hankelepingu hilisema sõlmimise võrra tööde teostamise periood edasi.