Grįžti į sąrašą

Vyriausybės taupymo lakštų platinimo internetinio portalo, įskaitant išmaniąją programėlę, sukūrimo IR DIEGIMO paslaugos

Išanalizuota

Lietuvos Respublikos finansų ministerija

Rinkos konsultacijaCPV: 72230000 - Vartotojų programinės įrangos kūrimo paslaugos
ID: 72568222026-04-03 14:47
Atidaryti CVP IS

Aprašymas

Perkami Lietuvos Respublikos Vyriausybės taupymo lakštų platinimo internetinio portalo, įskaitant išmaniąją programėlę, sukūrimo ir diegimo paslaugos. Šio portalo tikslas – suteikti fiziniams ir juridiniams asmenims galimybę nuotoliniu būdu įsigyti, valdyti ir išpirkti valstybės taupymo lakštus, užtikrinant saugumą ir patogumą. Be to, bus teikiamos ir portalo priežiūros bei vystymo paslaugos.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas per pastaruosius 3 (trejus) metus (skaičiuojant nuo paskutinės pasiūlymų pateikimo termino pabaigos) arba per laiką nuo Tiekėjo įregistravimo dienos (jeigu Tiekėjas vykdo veiklą mažiau nei 3 (tris) metus), tinkamai įdiegė elektroninių sandorių informacinę sistemą, kurios vertė yra ne mažesnė kaip 65.000,00 (šešiasdešimt penki tūkstančiai) Eur be PVM.
  • 2Tiekėjo patirtis kvalifikacijai pagrįsti yra tinkama tuo atveju, jeigu pasiūlymo pateikimo metu kurta ir/ar atnaujinta ir/ar pertvarkyta elektroninių sandorių informacinė sistema (ar atitinkamas paslaugos rezultatas) yra perduota gamybinei eksploatacijai ir atitinka toliau nurodomas sąlygas: - pasiūlymo pateikimo metu sukurta ir/ar atnaujinta ir/ar pertvarkyta elektroninių sandorių informacinė sistema prieinama ir naudojama išorinių naudotojų (gyventojų ir/ar verslo subjektų); - pasiūlymo pateikimo metu sukurta ir/ar atnaujinta ir/ar pertvarkyta elektroninių sandorių informacinė sistema, turinti bent 1 (vieną) integracinę sąsają su kita informacine sistema.
  • 3Projekto vadovas: a) turi tarptautiniu mastu pripažįstamą projektų valdymo kvalifikaciją; b) Per paskutinius 3 (tris) metus vadovavo bent 1 (vienam) informacinės sistemos kūrimo ir (ar) diegimo ir (ar) vystymo projektui.
  • 4Informacinės sistemos architektas: a) Turi tarptautiniu mastu pripažįstamą sistemų architekto kvalifikaciją; b) Per pastaruosius 3 (trejus) metus projektavo architektūrą bent 1 (viename) projekte kurio metu buvo sukurta ir (ar) atnaujinta ir (ar) pertvarkyta informacinė sistema (informacinės sistemos darbai baigti, sistema priduota eksploatacijai), ir kuriame atliko informacinės sistemos architektūros projektavimo darbus ir (ar) parengė informacinės sistemos architektūros reikalavimus (specifikaciją).
  • 5Programuotojas: a) turi tarptautiniu mastu pripažįstamą programuotojo kvalifikaciją; b) per pastaruosius 3 metus atliko programavimo darbus bent 1 (viename) IS kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo projekte, kur išorinių el. paslaugų naudotojų skaičius vienu metu ne mažesnis kaip 50 ir buvo panaudota programavimo kalba, reikalinga pasiūlyme pateiktam sprendimui įgyvendinti.
  • 6Mobiliosios programėlės programuotojas: a) Turi tarptautiniu mastu pripažįstamą programuotojo kvalifikaciją; b) Per pastaruosius 3 metus atliko programavimo darbus bent 1 (viename) mobiliosios programėlės kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo projekte, kur išorinių el. paslaugų naudotojų skaičius vienu metu ne mažesnis kaip 50 ir buvo panaudota programavimo kalba, reikalinga pasiūlyme pateiktam mobiliosios programėlės sprendimui įgyvendinti.
  • 7Sistemų integravimo specialistas: Per pastaruosius 3 (trejus) metus vykdė informacinių sistemų integravimo veiklas bent 1 (viename) IT paslaugų kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo (modernizavimo) projekte, įgyvendinant integracines sąsajas.
  • 8UX/UI projektavimo specialistas: Per paskutinius 3 (tris) metus dalyvavo ne mažiau kaip 1 (viename) IT paslaugų kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo (modernizavimo) projekte, kuriame atliko: - Naudotojo patirties (UX) analizę ir tyrimus; - Vartotojo sąsajos (UI) sprendinių projektavimą ir prototipų kūrimą.
  • 9Informacinių sistemų testuotojas: a) Tarptautiniu lygiu pripažįstama testuotojo kvalifikacija. b) per pastaruosius 3 (trejus) metus bent 1 (viename) IT paslaugų diegimo ir (ar) kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo projekte, vykdė informacinių sistemų testavimo veiklas (pvz., funkcinį, integracinį ir (ar) naudotojų priėmimo testavimą).
  • 10IT saugos specialistas: - turi tarptautiniu mastu pripažįstamą IT saugos specialisto kvalifikaciją. - per pastaruosius 3 (trejus) metus bent 1 (viename) IT sistemų kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo projekte vykdė informacinių sistemų ir (ar) registro duomenų saugumo užtikrinimo veiklas.

Techniniai reikalavimai

Integracijos

  • 1Portalas bus integruotas su Valstybės informacinių išteklių sąveikumo platforma (VIISP) išorės vartotojų autentifikavimui. Taip pat planuojama turėti ir atsarginį autentifikacijos būdą VIISP neveikimo atvejui.
  • 2Lėšų surinkimui apmokant per el. bankininkystę bus naudojamasi trečiosios šalies paslaugomis. Planuojama integracija su dviem mokėjimo paslaugų teikėjais (pagrindiniu ir atsarginiu), veikiančiais pagal PSD2 reikalavimus.
  • 3Integracija su VIKSVA turės užtikrinti: Emisijos duomenų gavimą iš VIKSVA ir sandorių duomenų perdavimą į VIKSVA. Priešlaikinio išpirkimo, išpirkimo ir atkarpos mokėjimo inicijavimą pateikiant mokėjimų informaciją į VIKSVA.
  • 4Integracijos su Nasdaq CSD Lietuvos filialu turės užtikrinti emisijos duomenų perdavimą Nasdaq CSD Lietuvos filialui emisijos dydžio ir sąlygų registravimui po pirkimo, dalinio ar galutinio išpirkimo bei atkarpos mokėjimų.
  • 5Naujienlaiškių, transakcijinių laiškų siuntimas turi būti numatytas SMTP protokolu. SMTP serverio prisijungimus pateiks Perkančioji organizacija.
  • 6Integracija su VMI turės užtikrinti reikiamų duomenų atidavimą VMI. Preliminariai turės būti formuojami XML failai.
  • 7Sandorių patvirtinimui el.parašu bus naudojamasi trečiosios šalies paslaugomis.
  • 8Turi būti realizuojama integracija su Google Analytics, naudojant Finansų ministerijos pateiktą paskyrą. Turi būti galimybė integruoti Google Tag Manager kodą į svetainę. Diegėjas turi sukonfigūruoti Google Tag Manager darbui su Google Analytics, užtikrinant teisingą duomenų rinkimą ir perdavimą.
  • 9Slapukų valdymui portale turi būti numatyta integracija su slapukų valdymo įrankiu, pvz. CookieBot ar lygiaverčiu įrankiu.
  • 10Visi mokėjimai turi būti inicijuojami per MIPT API, o Klientas turi būti nukreipiamas į banko aplinką autentifikacijai ir mokėjimo patvirtinimui. Sistema negali inicijuoti mokėjimo tiesiogiai banke, apeidama MIPT.
  • 11Sistema privalo priimti MIPT siunčiamus callback pranešimus apie mokėjimo būsenos pasikeitimą. Callback turi būti apdorojamas idempotentiškai — pakartotiniai pranešimai negali keisti galutinės būsenos ar sukelti pakartotinių veiksmų. Callback turi būti saugomas žurnale su gavimo laiku, mokėjimo ID, būsena, žaliu MIPT payload.
  • 12Visi ryšiai su MIPT turi vykti per HTTPS (TLS 1.3+). Callback endpoint turi būti apsaugotas pasirašytais pranešimais (HMAC arba analogiškas mechanizmas), arba IP whitelisting, arba OAuth 2.0 / API key.
  • 13Portalas turi priimti ir saugoti šiuos iš VIKSVA gaunamus emisijų parametrus: ISIN kodas; Emisijos pavadinimas; Emisijos trumpas kodas (ticker); Nominali vertė; Valiuta; Palūkanų norma; Palūkanų periodiškumas; Palūkanų mokėjimo data (-os); Platinimo pradžios ir pabaigos datos; Platinimo kaina (-os); Išpirkimo data; Priešlaikinio išpirkimo pradžios ir pabaigos datos; Priešlaikinio išpirkimo kaina (-os).
  • 14Emisijų parametrai, gauti iš VIKSVA, yra tik skaitomi (read-only) portale. Jų keisti per portalo TVS negalima. Išimtis: portalo administratorius gali koreguoti tuos laukus, kurie nėra tiesiogiai sinchronizuojami iš VIKSVA, jei tai numatyta administravimo procedūrose.
  • 15Visiems per portalą platinamiems VTL naudojamas vienas valstybės iždo IBAN sąskaitos numeris. Portalas gauna šį IBAN iš VIKSVA atskirai nuo emisijų sąlygų. Portalas naudoja šį IBAN kaip mokėjimo gavėjo sąskaitą platinimo sandorio apmokėjimo metu, automatiškai pateikiamą investuotojui pirkimo mokėjimo inicijavimo metu per MIPT.
  • 16Portalas turi teikti VIKSVA struktūrizuotą agreguotų sandorių ir operacijų ataskaitą kiekvienai darbo dienai. Ataskaitos turinys: Agr. Id; Emisija (ISIN); Operacijos tipas (platinimas / galutinis išpirkimas- / priešlaikinis išpirkimas / palūkanos); Laukiama lėšų gavimo ar planuojama mokėjimo data; Bendra sandorių suma; Sandorių ar operacijų skaičius, patenkantis į agreguotą sandorį (be individualių duomenų).
  • 17Portalas automatiškai grupuoja išeinančius mokėjimus į PAIN.001 žinutes pagal: Emisiją (ISIN kodą); Operacijos tipą (galutinis išpirkimas / priešlaikinis išpirkimas / palūkanos); Mokėjimo (value) datą.
  • 18Portalas turi palaikyti paketo patvirtinimo seką: Portalas generuoja PAIN.001 ir pateikia VIKSVA patvirtinimui su kontroliniais duomenimis. Gavus patvirtinimą – Gateway vykdo mokėjimus ir grąžina Portalui vykdymo ID. Gavus atmetimą – Portalas registruoja priežastį audito žurnale; pranešama administratoriui.
  • 19Portalo ir VIKSVA integracija realizuojama REST API pagrindu. Mokėjimų žinutėms – ISO 20022 standartas (PAIN.001 ir patvirtinimo pranešimai); Sąskaitos srautams – CAMT.053 arba VIKSVA palaikomas lygiavertis formatas; Atsarginis duomenų mainų kanalas – SFTP.
  • 20Visi API kvietimai tarp Portalo ir VIKSVA autentifikuojami naudojant OAuth 2.0 (client credentials flow) arba mutual TLS (mTLS).
  • 21Visi išorinių sistemų callback turi būti tikrinami pagal parašą, laiko žymą ir šaltinio IP adresą, kad būtų išvengta suklastotų ar pakartotinių (replay) užklausų.

Našumas ir Greitaveika

  • 1Portalo greitaveika turi būti planuojama numatant vienu metu dirbančių 100 vartotojų skaičių ir skaičiuojant, kad kiekvienas iš jų atlieka atsitiktinį veiksmą kas 2 s.
  • 2Portalo paleidimas, t. y. laikas kai vartotojas inicijuoja portalo paleidimą iki pilno portalo užkrovimo, neturi viršyti 2 sekundžių naudojant vidutinio lygio kompiuterį ar mobilųjį įrenginį ir vidutinį tinklo greitį (pvz. 4G).
  • 3Atsakas naršyklėje į vartotojo atliktą veiksmą neturi viršyti 1 s.
  • 4Ataskaitų generavimas, bet kokie kiti paketiniai darbai (failų importas) neturi viršyti 30 s.
  • 5Ilgiau nei 5 s. trunkančių užklausų atveju turi būti numatytas progreso indikatorių rodymas.
  • 6Minimalūs projektiniai rodikliai: ne mažiau kaip 100 vienalaikių vartotojų; ne mažiau kaip 5 sandoriai per minutę normaliu režimu; sistemos atsako laikas piko metu neturi viršyti 3 s. 95 % užklausų; neturi būti prarandami ar dubliuojami sandoriai esant maksimaliam apkrovos lygiui.
  • 7Turi būti atliktas portalo užsikrovimo greičio testas „PageSpeed Insights“. Portalo surinktų balų skaičius turi būti ne mažesnis kaip 70 balų iš 100 mobiliajai ir stacionariai versijoms.
  • 8Turi būti galimybė naudoti naršyklės spartinimą (browser caching), kad statiniai failai (pvz., CSS, JavaScript, paveikslėliai) būtų saugomi vartotojų naršyklėse.
  • 9Svetainė turi palaikyti serverio pusės spartinimo (server caching) sprendimus, siekiant sumažinti duomenų bazės užklausų skaičių.

Saugumas ir Duomenų Apsauga

  • 1Portalas ir visi jo komponentai (Parduotuvė, TVS, Programėlė, API, duomenų bazės ir integracijos) turi būti projektuojami, kuriami ir diegiami vadovaujantis BDAR 25 straipsnyje nustatytais pritaikytosios duomenų apsaugos ir standartizuotosios duomenų apsaugos principais.
  • 2Diegėjas privalo užtikrinti duomenų minimizavimą, tikslų apribojimą, saugojimo terminų valdymą, prieigos kontrolės ribojimą pagal mažiausios būtinos prieigos principą, duomenų subjektų teisių įgyvendinimo galimybes ir techninių bei organizacinių saugumo priemonių integravimą į Portalo architektūrą.
  • 3Asmens duomenys, tvarkomi Portale ir susijusiose sistemose, turi būti saugomi ir apdorojami tik Europos ekonominės erdvės teritorijoje.
  • 4Testavimo ir programavimo aplinkose draudžiama naudoti realius asmens duomenis. Diegėjas privalo sukurti ir naudoti sintetinį arba anonimizuotą duomenų rinkinį, kuris negali būti atsekamas iki realių duomenų subjektų.
  • 5Prieiga prie duomenų ir funkcijų turi būti suteikiama tik pagal mažiausios būtinos prieigos principą, atsižvelgiant į vartotojo vaidmenį.
  • 6Asmens duomenys turi būti šifruojami tiek perdavimo metu („in transit“), tiek saugojimo metu („at rest“), naudojant šiuolaikinius kriptografinius standartus.
  • 7Portalas turi atitikti Kibernetinio saugumo reikalavimų apraše, patvirtintame Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimus Nr. 818, nustatytus reikalavimus, įskaitant apsaugos nuo neautentifikuotos prieigos, nesankcionuoto vartotojo sesijos perėmimo, nesankcionuoto duomenų perėmimo ar jų įterpimo, žalingo kodo įterpimo (Injection, XSS (Cross-sitescripting)), žalingų bylų įkėlimo (turi būti galimybė įkelti bylas tik su tam tikrais plėtiniais, patikrinti bylos turinį, metaduomenis ir pan.).
  • 8Slapti duomenys (pvz. slaptažodžiai, API raktai, integracijų raktai, šifravimo raktai) negali būti saugomi programos kode, konfigūraciniuose failuose ar žurnaliniuose įrašuose. Turi būti naudojamas centralizuotas slaptų duomenų valdymo sprendimas (secrets vault) su prieigos kontrole ir audito įrašais.
  • 9Ryšiai turi būti šifruojami, taikant šiuolaikinius kriptografinius standartus; silpni protokolai ir šifrai turi būti išjungti.
  • 10Sistema turi užtikrinti galimybę naudotis saugiu HTTPS ryšiu, anti-DDoS apsaugą naudojant interneto skydą pvz : CloudFlare ar kitą jam prilygstantį produktą bei ne mažesnį nei TLSv1.3 ryšio standartą. Portalui (ir API, jei taikoma) turi būti taikoma aplikacinio lygmens apsauga (L7) naudojant WAF.
  • 11Turi būti realizuotos priemonės, užtikrinančios centralizuotą žurnalinių įrašų surinkimą iš visų portalo kuriamų komponentų. Turi būti taikomi užklausų trasavimo (distributed tracing) principai.
  • 12Portale turi būti atliekamas vartotojų veiksmų auditavimas, turi būti kaupiama ši informacija: kas atliko veiksmą (vartotojas), kada atliko veiksmą (data), kokius duomenis atnaujino, kokius duomenis įterpė, kokius duomenis pašalino.
  • 13Žurnaliniuose įrašuose negali būti saugomi slaptažodžiai, sesijos ID, TOTP seed’ai ar kiti slapti duomenys.
  • 14Žurnaliniai įrašai turi būti apsaugoti nuo modifikavimo ir trynimo. Žurnaliniai įrašai turi būti saugomi tik skaitymui (append-only). Prieiga prie žurnalinių įrašų turi būti ribojama pagal RBAC principą. Žurnaliniai įrašai turi būti šifruojami saugojimo metu (AES256 arba lygiavertis algoritmas).
  • 15Žurnaliniai įrašai turi būti saugomi ne trumpiau kaip 1 metus (jei nėra kitų teisinių reikalavimų). Incidentų žurnaliniai įrašai turi būti saugomi ne trumpiau kaip 2 metus.
  • 16Sistema turi naudoti saugius sesijų identifikatorius, generuojamus pagal OWASP rekomendacijas (ne mažiau kaip 128 bitų entropija). Sesijos identifikatorius turi būti saugomas tik HTTP‑only ir Secure žymomis pažymėtame slapuke.
  • 17Maksimalus sesijos galiojimo laikas negali viršyti 8 valandų, nepriklausomai nuo aktyvumo.
  • 18Po sėkmingo prisijungimo turi būti sugeneruota nauja sesija (session fixation prevencija). Po atsijungimo sesija turi būti nedelsiant sunaikinta serveryje.
  • 19Visi API endpoint’ai turi būti apsaugoti autentifikavimo mechanizmu (API raktai, OAuth 2.0, arba kitas saugus metodas). API raktai turi būti generuojami atsitiktinai, ne mažiau kaip 128 bitų entropijos. API raktai negali būti perduodami URL parametruose. API raktai turi būti saugomi tik serverio pusėje ir niekada nerodomi vartotojo sąsajoje.
  • 20Visi duomenys tarp kliento ir serverio turi būti perduodami naudojant TLS 1.3 arba naujesnę versiją. Negalima naudoti pasenusių protokolų (TLS 1.0, TLS 1.1, TLS 1.2, SSL). Negalima naudoti silpnų šifravimo rinkinių (cipher suites). HTTP turi būti automatiškai nukreipiamas į HTTPS (HSTS). API turi naudoti tik HTTPS — HTTP negali būti palaikomas net testinėje aplinkoje.
  • 21Visi jautrūs duomenys turi būti šifruojami diske naudojant AES‑256 arba lygiavertį algoritmą. Duomenų bazės atsarginės kopijos taip pat turi būti šifruojamos. Šifravimo raktai turi būti saugomi atskirai nuo duomenų (pvz., HSM, Key Vault). Raktų rotacija turi būti atliekama periodiškai (min. kartą per metus).
  • 22Slaptažodžiai turi būti saugomi naudojant bcrypt, Argon2 arba PBKDF2. Negalima naudoti SHA‑1, SHA‑256 ar kitų bendros paskirties hash’ų. Slaptažodžiai turi būti druskinami (salt) ir iteruojami.
  • 23Visi vidiniai ryšiai tarp mikroservisų turi būti šifruoti (mTLS).
  • 24Konfigūracijos failai turi būti šifruojami, jei juose yra slapti duomenys (pvz., API raktai, DB slaptažodžiai).
  • 25Produkcinėje aplinkoje turi būti išjungtas debug režimas. Produkcinėje aplinkoje negali būti naudojami testiniai raktai, testiniai sertifikatai ar testiniai vartotojai. Produkcinėje aplinkoje negali būti įjungti diagnostiniai endpoint’ai (pvz., /health/debug, /metrics/raw, /config). Testavimo duomenys negali būti maišomi su realiais duomenimis.
  • 26Sistema turi turėti mechanizmus, leidžiančius aptikti saugumo incidentus, įskaitant nesėkmingų prisijungimų šuolius, įtartinus API kvietimus, neįprastą vartotojų elgseną, konfigūracijos pakeitimus, bandymus apeiti prieigos kontrolę. Aptikti incidentai turi būti nedelsiant registruojami žurnaliniuose įrašuose.
  • 27Diegėjas privalo atlikti statinę kodo analizę (SAST) ir dinaminę aplikacijos saugumo analizę (DAST). Aptikti kritiniai ir aukšto lygio pažeidžiamumai turi būti pašalinti prieš diegiant į produkcinę aplinką.
  • 28Apkrovos testavimas turi užtikrinti, kad nebus prarandami ar dubliuojami sandoriai esant maksimaliam apkrovos lygiui.
  • 29Portalo duomenų bazė yra vienintelis pirminis duomenų šaltinis (source of truth) visiems duomenims, susijusiems su išorės vartotojais, jų inicijuotais mokėjimais, mokėjimų būsenomis, sandoriais ir kitais Portalo veikimo procesais.
  • 30Sandorio duomenys turi būti saugomi 10 metų pagal finansų apskaitos ir archyvavimo reikalavimus. Techniniai žurnalai (IP, įrenginys, naršyklė) saugomi 2 metus, nebent teisės aktai nustato ilgesnį terminą.
  • 31Visi sandorio duomenys turi būti šifruojami tiek perdavimo metu (TLS 1.3+), tiek saugojimo metu.
  • 32Sistema negali saugoti Kliento banko prisijungimo ar autentifikavimo duomenų (pvz., Smart-ID kodų, banko slaptažodžių, PIN kodų).
  • 33Mokėjimai turi būti inicijuojami per licencijuotą mokėjimų inicijavimo paslaugų teikėją (MIPT), veikiančią pagal PSD2 reikalavimus.
  • 34Sistema gali perduoti duomenis tik šiems subjektams: MIPT – tik tuos duomenis, kurie būtini mokėjimo inicijavimui. Bankai – tik per MIPT, sistema tiesiogiai su bankais nebendrauja. Nasdaq CSD Lietuvos filialas – tik tuos duomenis kurie būtini VTL registracijai bendrojoje vertybinių popierių sąskaitoje. Valstybinės institucijos – tik teisės aktų nustatytais atvejais (pvz., VMI, FNTT, audito institucijos). IT paslaugų teikėjai – tik kaip duomenų tvarkytojai, pagal sutartį ir BDAR 28 str.
  • 35Prieiga prie šifravimo raktų turi būti ribojama ir audituojama.
  • 36Duomenys gali būti perduodami trečiosioms šalims tik su Perkančiosios organizacijos leidimu. Perduodami duomenys turi būti apsaugoti šifravimu. Trečiosios šalys negali naudoti duomenų jokiais kitais tikslais, nei numatyta sutartyje.
  • 37Visi CI/CD veiksmų žurnalai turi būti registruojami ir saugomi.
  • 38CI/CD sistemoje negali būti saugomi slaptažodžiai, API raktai ar kiti slapti duomenys nešifruota forma. Visi slapti duomenys turi būti saugomi saugioje raktų saugykloje (pvz., Vault, KMS).
  • 39CI/CD sistema negali turėti prieigos prie produkcijos duomenų.
  • 40Testavimo ir programavimo aplinkose negali būti naudojami realūs produkciniai duomenys. Jei būtina naudoti duomenų kopijas, jos turi būti anonimizuotos arba pseudonimizuotos. Produkciniai duomenys negali būti eksportuojami į neprodukcinę aplinką be Perkančiosios organizacijos leidimo.
  • 41Produkcinė aplinka turi būti izoliuota nuo kitų aplinkų tinklo ir prieigos prasme.
  • 42Prieiga prie kiekvienos aplinkos turi būti suteikiama pagal mažiausios privilegijos principą.
  • 43Diegėjas privalo pateikti Perkančiajai organizacijai šiuos dokumentus: Sistemos architektūros aprašą su saugumo komponentais. Kietinimo (hardening) aprašą arba nuorodas į taikytus standartus. Priklausomybių ir komponentų sąrašą (Software Bill of Materials, SBOM). Saugumo testavimo (SAST/DAST) ataskaitas arba jų santraukas.

Bendrieji Portalo Reikalavimai

  • 1Portalas turi būti projektuojamas ir kuriamas moduliniu principu, užtikrinant sistemos lankstumą ir lengvas plėtimo galimybes.
  • 2Portalas turi būti projektuojamas ir kuriamas užtikrinant sistemos funkcijų aukštą prieinamumą (high availability) su RTO (Recovery Time Objective) ne ilgesniu kaip 2 valandos ir RPO (Recovery Point Objective) ne ilgesniu kaip 15 minučių.
  • 3Turi būti numatytas ir dokumentuotas Veiklos atstatymo po incidento (Disaster Recovery) scenarijus, apimantis paslaugos atkūrimo veiksmų seką, failover mechanizmą, duomenų atkūrimo procedūrą, atsakomybės paskirstymą ir periodinį Veiklos atstatymo testavimą (ne rečiau kaip 1 kartą per metus).
  • 4Kritiniai portalo komponentai (aplikacijų serveriai, API sluoksnis, duomenų bazė) turi būti realizuoti taip, kad jų gedimas nesukeltų visiško sistemos neveikimo. Turi būti užtikrintas automatinis paslaugos perjungimas (failover) be rankinio įsikišimo.
  • 5Portalas turi būti projektuojamas ir kuriamas užtikrinant sistemos plečiamumą (scalability), t. y. sistemos pajėgumus turi būti galima didinti tiek horizontaliai tiek vertikaliai nekeičiant programinio kodo.
  • 6Portalas turi būti realizuotas lietuvių kalba, turi būti numatyta galimybė ateityje lengvai pridėti kitas kalbas.
  • 7Portalo savybės ir dizainas turi būti pritaikyti neįgaliesiems, atitikti prieinamumo reikalavimus pagal WCAG 2.2 AA principus.
  • 8Maksimalus bendras Parduotuvės portalo sukūrimo, įdiegimo, ištestavimo, išbandymo ir parengimo bei pateikimo darbinei eksploatacijai veiklų atlikimo terminas – 7 mėnesiai nuo sutarties pasirašymo dienos.
  • 9Portalas turi būti pasiekiamas ne mažiau kaip 99,5% laiko.
  • 10Planiniai portalo atnaujinimo darbai turi būti atliekami nuo 22:00 iki 7:00 Lietuvos laiku.
  • 11Diegėjas turi užtikrinti neatlygintiną įdiegtos programinės įrangos garantinę priežiūrą (suteiktų paslaugų pagal Techninę specifikaciją trūkumų ir klaidų šalinimą) ne trumpesnį nei 12 mėnesių nuo Portalo pateikimo darbinei eksploatacijai perdavimo ir priėmimo akto pasirašymo dienos.
  • 12Kritinės klaidos, įtakojančios Portalo neveikimą arba klaidingą duomenų tvarkymą turi būti pašalintos ne vėliau kaip per vieną darbo dieną.
  • 13Reakcijos laikas po pranešimo apie kritinę klaidą - ne ilgesnis kaip 30 min.
  • 14Reakcijos laikas po pranešimo apie klaidą - ne ilgesnis kaip 2 val.

Portalo Turinio Valdymas (TVS)

  • 1TVS administravimo ir valdymo priemonės turi būti prieinamos per atskirą administravimo vartotojo sąsają. TVS turi turėti turinio publikavimo tvirtinimo procesą (workflow), leidžiantį Turinio tvarkytojui parengti pakeitimus, o Administratoriui juos patvirtinti arba atmesti.
  • 2TVS valdymas ir konfigūravimas vykdomas interneto naršyklės pagalba.
  • 3Visi vidaus vartotojų atlikti turinio objektų pakeitimai turi būti versijuojami. Versijų žurnaluose turi būti registruojama: kas atliko pakeitimą, kada atliko, kokie laukai buvo pakeisti; žurnalai turi būti apsaugoti nuo modifikavimo ir saugomi pagal nustatytus terminus. Turi būti numatyta interneto svetainės duomenų bazės ir svetainės informacijos automatinio atsarginio kopijavimo galimybė bei priemonės lengvai atstatyti atsitiktinai ištrintus turinio objektus. Turi būti realizuota automatinio archyvavimo galimybė, taip pat galimybė pagal poreikį peržiūrėti archyvuotas senesnes turinio objektų versijas, jas ištrinti.
  • 4TVS turi leisti valdyti (įvesti, keisti, šalinti) portalo turinį nenaudojant HTML kalbos žinių. Teksto redagavimo aplinka turi būti Microsoft Word ar kitų lygiaverčių programų aplinkai.
  • 5Redaktoriuje turi būti galimybė tiesiogiai redaguoti patį HTML kodą. HTML redagavimo funkcija turi būti apsaugota nuo XSS rizikų: sistema turi automatiškai filtruoti pavojingus HTML elementus ir atributus (pvz., <script>, onload=, onclick=).
  • 6TVS priemonėmis turi būti galima administruoti portalo struktūrą. Turi būti numatyta galimybė kurti naujus neriboto gylio puslapius.
  • 7Turi būti numatyta galimybė keisti informacijos blokų, elementų (reklamjuosčių (angl. banners)) padėtį, įkelti, naikinti papildomus blokus, koreguoti esamus blokus. Failų įkėlimo funkcija turi tikrinti failų tipą, dydį ir turinį, kad būtų išvengta žalingų failų įkėlimo; leidžiami tik saugūs plėtiniai (pvz., PDF, JPG, PNG).
  • 8Turi būti sukurtas TVS funkcionalumas, leidžiantis administruoti (peržiūrėti, redaguoti, šalinti) dažniausiai užduodamus klausimus (DUK): Tvarkyti klausimų atsakymų tekstus; Grupuoti klausimus pagal temas; Sudaryti, keisti klausimų hierarchiją.
  • 9TVS turi leisti administruoti asmens duomenų saugumo politikos informaciją. Turi būti galima keisti turinio tekstą, pateikti nuorodas į detalius informacijos tvarkymo aprašymus, nustatyti galiojimo trukmę, kitus parametrus.
  • 10TVS turi leisti administruoti portalo naudojimosi taisykles.
  • 11TVS turi turėti priemones administruoti VTL emisijas (jų katalogus). VTL emisijų duomenys bus importuojami iš VIKSVA, tačiau turi būti galimybė importuoti VTL emisijų sąrašą ir iš failo.
  • 12TVS turi turėti emisijų pakeitimų tvirtinimo mechanizmą. Tvirtintojui patvirtinus arba atmetus pakeitimus, pakeitimų autorius turi gauti pranešimą el. laišku. Visi emisijų pakeitimai turi būti registruojami audito žurnale su informacija apie autorių, tvirtintoją, datą ir pakeistų laukų sąrašą.
  • 13TVS turi turėti priemones administruoti vartotojų teises ir roles (teisių grupes). TVS turi būti numatytos priemonės tvarkyti teisių ir rolių sąrašą.
  • 14TVS turi turėti priemones administruoti vartotojus: Sukurti Portalo vartotoją; Blokuoti Portalo vartotoją; Atblokuoti Portalo vartotoją; Suteikti Portalo vartotojams atitinkamas roles; Pašalinti suteiktas roles.
  • 15Administratorius negali keisti vartotojo sandorių ar finansinių duomenų; jis gali valdyti tik paskyrų būsenas ir roles. Kiekvienas rolės pakeitimas turi būti registruojamas audito žurnale su informacija apie keitėją, datą ir ankstesnę/naują rolę.
  • 16TVS turi turėti priemones valdyti klasifikatorius, kurti, redaguoti, šalinti (padaryti nenaudojamomis) klasifikatorių reikšmes. Turi būti galimybė importuoti klasifikatorius. Klasifikatorių pakeitimai turi būti versijuojami, kad būtų galima atsekti istorinius pakeitimus ir jų galiojimo laikotarpius.
  • 17Turi būti palaikomi neapsiribojant žemiau nurodyti specifiniai klasifikatoriai: Žinučių temos; Emisijų trukmė. Turi būti numatyta galimybė ateityje lengvai įvesti naujus klasifikatorius.
  • 18TVS turi būti funkcijos, leidžiančios administruoti naujienlaiškius, el. laiškų šablonus. Turi būti numatyta šablonų sąrašo peržiūra lentelės pavidalu, paieška, filtravimas, rūšiavimas. Turi būti numatytas esamų šablonų redagavimas, šalinimas, naujų kūrimas, kopijavimo galimybė. Kuriant šablonus turi būti naudojamas tekstinis redaktorius.
  • 19Turi būti sukurtas TVS funkcionalumas, leidžiantis Turinio valdytojui: Matyti Klientų pateiktų žinučių sąrašą; Galimybę žinutes rūšiuoti (pagal datą, atsakyta/neatsakyta ir pan.); Atsakyti (reply) į Klientų žinutes.

Sandorių Valdymas ir Pirkimas

  • 1Klientas sudarydamas sandorį (formuodamas užsakymą) vykdo šiuos veiksmus (vedlio principu): Sandorių krepšelio formavimas; Sandorių krepšelio peržiūra ir patvirtinimas; Banko sąskaitos pateikimas; Mokėjimo inicijavimas; VTL pirkimo sutarties formavimas; Sandorio būsenos pakeitimas.
  • 2Sistema turi rodyti tik tas emisijas, kurios šiuo metu yra platinamos. Sistema turi rodyti emisijos parametrus (nominali vieneto vertė, palūkanų norma, trukmė, išpirkimo data, maksimali investicijos suma (jei taikoma), platinimo laikotarpio pabaiga ir kt.).
  • 3Sistema turi tikrinti ribas (ar suma ≥ minimali suma; ar suma ≤ maksimali suma (jei taikoma); ar suma yra sveikas kartotinis nominalo).
  • 4Sistema turi sugeneruoti sandorio identifikatorių (sandorio ID) – unikalų ID, naudojamą mokėjimui. Sandorio ID turi būti globaliai unikalus, generuojamas deterministiniu būdu (pvz., UUID arba sisteminis ID su prefiksu), kad būtų užtikrintas vienareikšmis sandorio atsekamumas visose integracijose.
  • 5Mokėjimo paskirtis turi būti sugeneruota automatiškai pagal sandorio ID ir negali būti keičiama nei vidaus, nei išorės vartotojų.
  • 6Sistema turi rodyti sandorio būseną (Neapmokėtas, Laukiama banko patvirtinimo, Apmokėtas, Atmestas, Nepavykęs, Atšauktas (jei leidžiama)) ir automatiškai atnaujinti būseną pagal MIPT ir (ar) VIKSVA duomenis.
  • 7Mokėtojo duomenys (vardas ir pavardė) turi sutapti su Kliento duomenimis.
  • 8Sandoriui įgavus būseną SETTLED suformuojama VTL pirkimo sutartis.
  • 9Krepšelyje VTL emisijos su tais pačiais ISIN kodais, kaina ir galutinio išpirkimo terminu turi būti konsoliduojamos, t. y. sumuojamos įtraukiant VTL emisiją į krepšelį.
  • 10Išorės vartotojas turi turėti galimybę koreguoti į krepšelį įtrauktas VTL emisijas: keisti įsigyjamų VTL kiekį.
  • 11Klientas turi nurodyti banko sąskaitą IBAN formatu, naudotiną palūkanoms bei išmokoms už išperkamus VTL gauti. Sąskaitos įvedimas turi būti privalomas, laukui vykdoma IBAN struktūros validacija, įskaitant Mod 97 kontrolės algoritmo tikrinimą.
  • 12Sistema turi galėti apskaičiuoti mokėtinas sumas priešlaikiniam išpirkimui, galutiniam išpirkimui ir palūkanų mokėjimams pagal aktyvius sandorius reikalingoms datoms tiek kiekvienam individualiam sandoriui, tiek agreguotiems sandoriams.
  • 13Klientas turi turėti galimybę paskyroje pateikti prašymą prieš laiko išpirkti (dalį ar visą) turimą (-as) emisiją (-as): Registruodamas prašymą turi galėti pasirinkti norimą išpirkti emisiją, nurodyti jos sumą (automatiškai nurodoma visa turima tos VTL emisijos suma, kurią galima koreguoti į mažesnę pusę). Priešlaikinio išpirkimo data parenkama arčiausia galima pagal VTL emisijos priešlaikinio išpirkimo sąlygas. Apmokėjimo informacija automatiškai paimama iš vartotojo paskyros.
  • 14Prašymas pasirašomas el.parašu per trečiąją šalį ir suformuojamas bei paskyroje patalpinamas prašymas pdf formatu.
  • 15Klientas paskyroje turi matyti pateiktą priešlaikinio išpirkimo prašymą ir turėti galimybę jį atšaukti iki VTL emisijos sąlygose nurodyto termino. Atšaukimas turi būti patvirtinamas el. parašu.
  • 16Sistema turi leisti dalinį portfelio perkėlimą (pvz., skirtingiems įpėdiniams). Portale turi būti aiškiai rodomas likutis kiekvienam vartotojui pagal emisiją po dalinio perkėlimo.
  • 17Po perkėlimo Portale atnaujinama mokėjimų gavėjo informacija: būsimi išpirkimai ir palūkanos siunčiami į naujojo savininko banko sąskaitą.

Technologijos ir Infrastruktūra

  • 1Duomenų bazė turi būti realizuota naudojant replikacijos mechanizmą (sinchroninį arba asinchroninį, pagrindžiant pasirinkimą), užtikrinant duomenų vientisumą ir atkūrimą pagal nustatytą RPO.
  • 2Programėlė turi būti realizuojama naudojant „cross-platform“ kūrimo karkasą (pvz., React Native, Flutter, .NET MAUI ar lygiavertį), užtikrinantį: vieningą kodo bazę iOS ir Android platformoms; ilgalaikį technologijos palaikymą (ne trumpesnį kaip 5 metai); aktyvią kūrėjų bendruomenę ir reguliarų atnaujinimą; galimybę perduoti ir perimti projektą kitam tiekėjui be esminių technologinių apribojimų.
  • 3Diegėjas turi numatyti pažeidžiamumų skanavimo įrankius (static code analysis). Įrankiai turi būti integruoti į automatinį CI/CD procesą.
  • 4Portalo centralizuotai duomenų bazei turi būti parinkta brandi reliacinė DBVS, užtikrinanti transakcijų vientisumą, replikavimą/aukštą prieinamumą, atsarginių kopijų ir atstatymo scenarijus, audito ir prieigos kontrolės priemones. Pirmenybė teikiama Oracle DBVS.
  • 5Portalo duomenų saugykloms realizuoti turi būti numatytos Redis, MySql arba lygiavertės duomenų bazės.
  • 6Diegėjas turi numatyti, kad portalo komponentai pateikiami ir diegiami konteinerizuotoje aplinkoje kaip Docker konteineriai, naudojant konteinerių orkestravimo sprendimą (pvz., Docker Swarm ar lygiavertį), užtikrinant aukštą prieinamumą, automatinį paslaugų perkėlimą gedimo atveju, horizontalų mastelio didinimą ir „zero downtime“ diegimą.
  • 7Diegėjas turi numatyti, kad programinio kodo, aplikacijų, duomenų bazių atnaujinimas reikiamose aplinkose būtų atliekamas automatizuotai, be papildomų vartotojo veiksmų ir su minimaliomis konfigūravimo pastangomis (zero touch deployment).
  • 8Diegėjas turi numatyti portalo priežiūrą (pakeitimų, atnaujinimų diegimą) nestabdant sistemos (zero downtime maintenance).
  • 9Diegėjas turi užtikrinti Portalo veikimą Perkančiosios organizacijos pateiktoje virtualioje infrastruktūroje (valstybės IT paslaugų teikėjo valdomoje valstybės informacinių išteklių infrastruktūroje) su galimybe perkelti ją į kitą duomenų centrą, neatliekant esminių sistemos programinių komponentų perkūrimo darbų.
  • 10Infrastruktūra turi užtikrinti geografinį atsparumą, kai tai leidžia valstybės IT paslaugų teikėjo architektūra. Kritiniai sistemos komponentai turi būti diegiami ne mažiau kaip dviejose atskirose fizinėse lokacijose ar nepriklausomuose infrastruktūros mazguose.
  • 11Diegėjas turi numatyti ir paruošti atitinkamus automatinio integravimo ir diegimo (Continuous Integration/Continuous Delivery (CI/CD)) įrankius (Jenkins, Bamboo arba lygiaverčius).
  • 12Portalo autorinės turtinės teisės turi būti perduotos ir priklausyti Perkančiajai organizacijai neribotą laiką po Portalo priėmimo-perdavimo akto pasirašymo.
  • 13Diegėjas privalo užtikrinti Portale naudojamų technologijų ir su jomis susijusios programinės įrangos legalumą, t. y. visos naudojamos programinės įrangos, naudojamų modulių licencijos turi būti atviro kodo arba Diegėjo įsigytos ar įsigyta jų prenumerata.
  • 14Turi būti užtikrinamas ilgalaikis technologijos palaikymas (ne trumpesnis kaip 5 metai) bei galimybė perduoti ir perimti projektą kitam tiekėjui be esminių technologinių apribojimų.

Vartotojų Valdymas ir Autentifikacija

  • 1Svečias jungdamasis per Valstybės informacinių išteklių sąveikumo platformą (VIISP) turi turėti galimybę pasirinkti vieną iš šių autentifikacijos būdų: Smart-ID, Mob. parašas, Elektroninė bankininkystė.
  • 2Autentifikacijos funkcionalumas turi užtikrinti duomenų saugumą pagal BDAR reikalavimus, vienodą vartotojo patirtį per visus įrenginius, sąsajos pritaikymą WCAG 2.2 AA lygmens prieinamumo standartams, aiškų naudotojo informavimą apie išorinių paslaugų naudojimą ir duomenų tvarkymą, galimybę susieti kelis autentifikavimo būdus su viena paskyra.
  • 3Kliento registracija vyksta tokiu eiliškumu: Autentifikacija; Paskyros duomenų patvirtinimas/įvedimas, sutikimų pateikimas; Registracijos patvirtinimas; Paskyros sukūrimas.
  • 4VIISP perduoti duomenys (vardas, pavardė ir asmens kodas) negali būti keičiami išorės vartotojo; sistema turi užtikrinti, kad šie laukai būtų tik skaitomi (read-only).
  • 5Paskyra turi būti aktyvuojama tik po el. pašto patvirtinimo. Registracijos nuoroda turi galioti ne ilgiau kaip 24 valandas.
  • 6Klientui neatliekant veiksmų ilgiau nei 5 min. jis turi būti automatiškai atjungiamas nuo paskyros.
  • 7Programėlė turi turėti įdiegtus pažangius biometrinės autentifikacijos metodus, įskaitant veido atpažinimą (Face Recognition) bei pirštų atspaudų nuskaitymą (Fingerprint Recognition), remiantis įrenginio operacinės sistemos palaikoma biometrinės tapatybės patvirtinimo infrastruktūra.
  • 8Portalo vartotojų vaidmenys ir prieigos teisės turi būti suprojektuotos taip, kad užtikrintų BDAR 5 straipsnio 1 f punkto (vientisumas ir konfidencialumas) ir 25 straipsnio reikalavimus, taikant mažiausios būtinos prieigos principą ir vaidmenimis grįstą prieigos valdymą (RBAC).
  • 9Vardinės administracinės paskyros: Portalo turinio administracinės paskyros turi būti vardinės, draudžiama naudoti bendras ar dalinamas paskyras.
  • 10Keturių akių principas kritiniams veiksmams: Kritiniai veiksmai (pvz., VTL sąlygų keitimas, klasifikatorių keitimas, parametrų keitimas, integracijų konfigūravimas) turi būti atliekami tik dviejų skirtingų Administratorių patvirtinimu.
  • 11Administratoriams turi būti privalomas dviejų faktorių autentifikavimas (MFA).
  • 12Sistema turi riboti prisijungimo bandymus, jei naudojami papildomi prisijungimo mechanizmai (pvz., Administratoriaus paskyros). Po 5 nesėkmingų bandymų paskyra turi būti automatiškai laikinai užblokuota (min. 15 min.).
  • 13Sistema turi turėti IP‑based ir user‑based bruteforce apsaugą. Turi būti taikomas rate limiting (pvz., max 10 užklausų per minutę vienam IP). Turi būti taikoma CAPTCHA arba kitas mechanizmas, jei aptinkamas įtartinas aktyvumas.
  • 14Prieiga prie CI/CD sistemos turi būti ribojama pagal mažiausios privilegijos principą.
  • 15Konfigūracijos pakeitimai turi būti peržiūrimi (4‑eyes principle).

Dokumentai18

  • 1_VTL platinimo portalas.RK.7z
  • 2 RK priedas. Minimalūs reikalavimai tiekejams1.docx
  • 3 RK priedas. ENV metodika.docx
  • 4 RK priedas. Portalo sukūrimo TS_EN.docx
  • 5 RK priedas. Minimalūs reikalavimai tiekejams_EN.docx
  • 6 RK priedas. ENV metodika_EN.docx
  • Invitation (kvietimas_EN).docx
  • Kvietimas.docx
  • 2862_7256822.pdf
  • 2 RK priedas. Minimalūs reikalavimai tiekejams1.docx
  • 3 RK priedas. ENV metodika.docx
  • 4 RK priedas. Portalo sukūrimo TS_EN.docx
  • 5 RK priedas. Minimalūs reikalavimai tiekejams_EN.docx
  • 6 RK priedas. ENV metodika_EN.docx
  • Invitation (kvietimas_EN).docx
  • 1 RK. priedas. Portalo sukūrimo TS.docx
  • Kvietimas.docx
  • 1 RK. priedas. Portalo sukūrimo TS.docx
tendis.lt · Sukurta recodin.lt