Grįžti į sąrašą

Lietuvos Respublikos miškų valstybės kadastro vystymo ir konsultacinių valandų paslaugos

Išanalizuota

VĮ Registrų centras (PV)

Rinkos konsultacijaCPV: 72267000 - Programinės įrangos priežiūros ir tvarkymo paslaugos
ID: 76058092026-04-28 09:27
Atidaryti CVP IS

Aprašymas

Perkamos Lietuvos Respublikos miškų valstybės kadastro (MVK) informacinės sistemos vystymo ir konsultacinės paslaugos. Paslaugos apims MVK funkcionalumo plėtojimą, esamų sprendimų modernizavimą ir ekspertines konsultacijas, siekiant užtikrinti sistemos veikimą bei atitiktį aukščiausiems kokybės ir saugumo standartams.

Kvalifikaciniai reikalavimai

  • 1Specialistas – GIS/IS architektas: Per pastaruosius 3 metus vykdė informacinių sistemų architekto funkcijas, kuriant informacinę sistemą, kuri atitinka šiuos reikalavimus: sistema veikia Esri technologijos pagrindu (panaudojant tokius koponentus, kaip pvz. ArcSDE, ArcGis Server, ArcGis data store ir pan).
  • 2Specialistas – GIS / FullStack programuotojas, t.y. (BackEnd + FrontEnd) (Mid): per paskutinius 5 metus turi ne mažiau kaip 2 metų FullStack programuotojo, dirbant su Esri (pvz.: ArcGIS Maps SDK for JavaScript, ArcObjects, ArcPy ir pan.) technologijomis, patirtį, kuriant informacines sistemas.
  • 3Tiekėjo siūlomo GIS / FullStack programuotojo papildoma patirtis: turi turėti patirties, kuriant informacines sistemas, integruojančias ir apdorojančias Miškų valstybės kadastro duomenis, įskaitant (bet neapsiribojant) GIS sprendimus, erdvinių duomenų analizę ar ataskaitų generavimą.
  • 4Tiekėjo siūlomas specialistas (-ai) turi gebėti bendrauti žodžiu ir raštu lietuvių kalba (ne blogesniu nei C1 lygiu pagal Bendruosius Europos kalbų matmenis). Tuo atveju, jei specialistas lietuvių kalbos nemoka, reikalavimas gali būti tenkinamas numatant, kad sutarties vykdymo metu bus užtikrintos vertimo žodžiu ir raštu paslaugos, kurios turi būti įskaičiuotos į pasiūlymo kainą.

Techniniai reikalavimai

Diegimo reikalavimai

  • 1Sistemos versijų diegimui į Pirkėjo Aplinkas Teikėjas turi parengti Diegimo planą.
  • 2Turi būti sukonfigūruotas duomenų rezervinio kopijavimo mechanizmas, aprašytos ir išbandytos duomenų atstatymo procedūros.
  • 3Sistemos versijų diegimas turi būti vykdomas etapais kiekvienai Sistemos naudojančiai tarnybinei stočiai atskirai.
  • 4Sistemos versijų diegimas turi būti vykdomas nurodyta tvarka: DEV aplinkoje įdiegiama nauja Sistemos versija; atliekami įdiegtos Sistemos versijos veikimo įvertinimas; po nesėkmingai veikimo įvertinimo, atliekami reikiami Sistemos pakeitimai ir diegimo procesas kartojamas; sėkmingai atlikus veikimą įvertinimą, diegimo procesas tęsiamas toliau; TEST aplinkoje įdiegiama nauja DEV aplinkoje sėkmingai ištestuota Sistemos versija; atliekami įdiegtos Sistemos versijos testai; nesėkmingai atlikus testus, atliekami reikiami Sistemos pakeitimai ir diegimo procesas kartojamas; sėkmingai atlikus testus, diegimo procesas tęsiamas toliau.
  • 5Versijos diegimo metu tarnybinė stotis, kurioje vykdomi versijos diegimo darbai, vartotojui bus neprieinama.
  • 6Teikėjas turės parengti pačios Sistemos ir ją sudarančių komponentų automatizuoto testavimo ir diegimo (CI/CD) procesus Pirkėjo naudojamoje priemonėje GitLab.
  • 7Teikėjo su Pirkėju suderinti ir sudaryti CI/CD procesai (Pipeline) turi užtikrinti: Artefaktų pagaminimą; Artefaktų ir kodo kokybės patikrinimą; Artefaktų ir kodo saugumo patikrinimą (Pirkėjas pateiks įrankius reikalingus kodo saugumui patikrinti); Automatinį testų vykdymą; Diegimą į testavimo aplinką; Diegimą į gamybinę aplinką.

Garantinė priežiūra

  • 1Garantinės priežiūros terminas yra 12 mėnesių nuo kiekvieno Vystymo ar Konsultacinių paslaugų priėmimo–perdavimo akto pasirašymo datos.
  • 2Garantinis aptarnavimas turi būti teikiamas sukurtos programinės įrangos funkcionalumui, gamybinės (PROD) ir testinės (TEST) aplinkos konfigūracijai, visai pateiktai dokumentacijai.
  • 3Garantinio aptarnavimo metu Teikėjas turės teikti šias bendras sistemos priežiūros paslaugas: Sistemos klaidų ar netikslumų registravimą, taisymą, testavimą, diegimą ir atnaujintų programinių priemonių išeities tekstų pateikimą Pirkėjui, Sistemos dokumentacijos tikslinimą pagal atliktus taisymus, konsultacijų apie sukurtą programinę įrangą teikimą garantiniais klausimais.
  • 4Reakcijos į kritinę problemą laikas: ne ilgiau kaip 2 Pirkėjo darbo laiko valandos.
  • 5Reakcijos į nekritinę problemą laikas: ne ilgiau kaip 4 Pirkėjo darbo laiko valandos.
  • 6Kritinės problemos sprendimo trukmė: ne ilgiau kaip 1 darbo diena nuo pranešimo apie gedimą gavimo.
  • 7Konsultacijos telefonu ir elektroniniu paštu (Hot Line) teikiamos darbo dienomis Pirkėjo oficialiai patvirtintu darbo laiku.
  • 8Turi būti galimybė visą parą registruoti problemas internetu bei stebėti problemų sprendimo būklę naudojant Teikėjo pateiktą klaidų registravimo įrankį arba Pirkėjo JIRA.

Testavimo reikalavimai

  • 1Turi būti atlikti Sistemos versijų testavimai, siekiant įsitikinti, kad įgyvendinti visi funkciniai ir nefunkciniai Techninės specifikacijos reikalavimai ir identifikuoti, užregistruoti bei ištaisyti funkcionalumo klaidas.
  • 2Turi būti atlikti šie vidiniai testavimai: Unit, Integration, Functional, Non-Functional, Security, Compatibility, Smoke.
  • 3Apkrovos ir našumo testavimas turi būti atliktas DEV aplinkoje, o Pirkėjo testavimo aplinkoje vykdys papildomą apkrovos ir našumo testavimą.
  • 4Integracinis testavimas (Integrity Testing) turi būti atliktas TEST aplinkoje su Pirkėjo darbuotojais.
  • 5Priėmimo testavimas (Acceptance Testing) turi būti atliekamas TEST aplinkoje dalyvaujant Teikėjui, Pirkėjui ir kitoms suinteresuotoms šalims, remiantis priėmimo testavimo planu ir scenarijais.
  • 6Testavimo metu turi būti vykdomas identifikuotų klaidų (problemų) registravimas elektronine forma Pirkėjo įrankyje JIRA.
  • 7Teikėjas turi parengti ir su Pirkėju suderinti testavimo planą ir testavimo scenarijus, kuriuose aprašoma testavimo metodika, apimtis, aplinka, scenarijų struktūra, grafikas, reikalingi duomenys ir priėmimo kriterijai.
  • 8Kai paslaugos teikimas apima ir testavimo veiksmus, Teikėjas turi užtikrinti testavimui reikalingus išteklius (testinius duomenis, įskaitant asmens duomenis, kai testavimo negalima atlikti su sintetiniais duomenimis).
  • 9Priėmimo testavimas turi būti vykdomas Pirkėjo įsigytos techninės įrangos pagrindu.
  • 10Teikėjas turės parengti ir pateikti visus testavimui reikalingus duomenis, įrankius ar kitas priemones.
  • 11Teikėjas turės sudaryti ir kitus testavimo duomenis, kurie bus reikalingi tam, kad patikrinti RPO funkcinius ir nefunkcinius reikalavimus.

Dokumentacijos reikalavimai

  • 1Visa Teikėjo rengiama Projekto dokumentacija turi būti parengta lietuvių kalba vadovaujantis bendrinės lietuvių kalbos taisyklėmis (išskyrus techninius dokumentus, kuriuose dalis informacijos gali būti pateikiama anglų kalba), iliustruoti schemomis, lentelėmis, grafikais bei kitomis vaizdinėmis priemonėmis, pateikiama medžiaga išdėstoma aiškiai, nuosekliai ir detaliai.
  • 2Teikėjo pataisyti dokumentai turi būti teikiami su matomais pakeitimais („track changes“ funkcija).
  • 3Dokumentų galutinės versijos turi būti pateiktos elektroniniu (MS Word arba kitu su Užsakovu suderintu redagavimui tinkamu formatu įrašant dokumentą (-us) į skaitmeninę laikmeną, o atskirtu Užsakovo nurodymu - popierinės.
  • 4Preliminarios (projektinės) versijos turi būti pateikiamos elektroniniu formatu elektroninio ryšio priemonėmis. Pastabos bei korekcijos dokumentų projektuose turi būti teikiamos MS Office programinio paketo (ar lygiaverčio) pakeitimų sekimo (track changes) bei komentavimo funkcijomis. Turi būti vykdomas pateikiamų dokumentų versijavimas (versijų kontrolė).
  • 5Visi Teikėjo parengti dokumentai turės būti suderinti su Pirkėju.
  • 6Dokumentų galutinės versijos turi būti pateiktos dviem formatais: redagavimui tinkamu elektroniniu (.doc, .docx, .pdf arba kitu su Pirkėju suderintu formatu) ir Teikėjo atsakingo asmens parašu (elektroniniu arba įprastu) pasirašytu formatu. Dokumentų tarpinės versijos teikiamos tik elektroniniu formatu.
  • 7Visa Teikėjo parengta Projekto dokumentacija turi būti patvirtinta Pirkėjo atsakingų asmenų, detaliau aprašyta Darbo reglamente.

Naudotojų valdymas ir auditavimas

  • 1Sistema turi automatiškai nutraukti naudotojų darbo seansą praėjus parametrais apibrėžtam neaktyvumo laikotarpiui ir informuoti apie atjungimo priežastį pranešimu. Sistemos administratoriui turi būti galimybė keisti neaktyvumo laikotarpio parametro reikšmę.
  • 2Turi būti numatytas naudotojų privalomas slaptažodžio keitimas kas nustatytą laikotarpį, kai autentifikavimo būdas pasirinktas „Sistemos priemonėmis“.
  • 3Sistemos naudotojų vardai, kiti asmens duomenys, slaptažodžiai turi būti saugomi su tinkamu prieigos kontrolės užtikrinimu ir informacijos šifravimu.
  • 4Sistemos naudotojui pagal jo pateiktą užklausą turi būti rodomi tik tie duomenys, kuriuos jis turi teisę peržiūrėti.
  • 5Neturi sudaryti sąlygų spėlioti slaptažodžius.
  • 6Neturi vaizduoti įvedamo slaptažodžio.
  • 7Turi būti vykdomas visų Sistemos komponentų funkcionalumo naudojimo (naudotojų atliekamų veiksmų) ir komponentų veikimo auditavimas.
  • 8Turi būti realizuotas audito įrašų tvarkymo komponentas, kuris gautų ir kauptų Sistemos veikimo bei naudojimo duomenis ir apsaugotų žurnalinius įrašus nuo nesankcionuoto ar netyčinio pakeitimo bei ištrynimo.
  • 9Atliekant auditavimo įrašo išsaugojimą duomenų bazėje, turi būti kaupiama: kas atliko veiksmą (vartotojas); kada atliko veiksmą (data, laikas).

Analizės ir projektavimo reikalavimai

  • 1Teikėjas analizės ir projektavimo etapų vykdymo metu turi atlikti detalią veiklos procesų ir poreikių analizę bei projektavimą ir parengti detalios reikalavimų analizės ir projektavimo dokumentus.
  • 2Detalios reikalavimų analizės dokumente turi būti pateikti pagal Techninės specifikacijos funkcinius ir nefunkcinius reikalavimus bei pagal Pirkėjo išsakytus poreikius parengti panaudos atvejai (Use Case) (panaudos atvejų diagramos ir detalūs panaudos atvejų aprašymai, nurodant žingsnius (pagrindinę eiga, alternatyvią eigą, išimtinę eigą) ir kitus apribojimus, naudojant UML (Unified Modeling Language) notaciją.
  • 3Turi būti atliktas visų Techninės specifikacijos funkcinių ir nefunkcinių reikalavimų susiejimas su detalios analizės dokumento turiniu (skyriais, panaudos atvejais, diagramomis ir pan.), siekiant aiškumo, kokiu būdu projektuojamas ir realizuojamas kiekvienas RPO reikalavimas.
  • 4Atliekant analizę ir projektavimą Teikėjas turi vykdyti susitikimus su Pirkėjo paskirtais veiklos specialistais ir kitų susijusių institucijų specialistais.

Sistemos vystymo metodika ir įrankiai

  • 1Sistemos vystymo paslaugos turi būti teikiamos remiantis inkrementiniu-iteraciniu informacinių sistemų įgyvendinimo būdu (Agile), kuomet sistemos savininko vaidmenį atlieka Pirkėjas, darbai planuojami vienos-dviejų savaičių iteracijomis.
  • 2Pradinį darbų apimties įvertinimą, vadovaudamasis taškine (SFT) metodika, pateikia Tiekėjas. Galutinė darbų apimtis ir valandų skaičius nustatomi Tiekėjui ir RC suderinus įverčius pagal metodikos taisykles.
  • 3Pirkimo paslaugos turi būti įgyvendinamos iteraciniu informacinės sistemos kūrimo būdu, taikant gerąsias „Agile“ programinės įrangos kūrimo metodų Scrum ir Kanban praktikas.
  • 4Sistemos pokyčių (vystymo, technologinių) poreikiai turi būti registruojami Pirkėjo Jira sistemoje Sistemos kūrimo projekte, pasirenkant Issue type Epic. Poreikis Epic skaidomas į Story, mažesnius produkto darbų sąrašo elementus.
  • 5Sistemos vystymo paslaugų teikimo metu sukurto išeities kodo kokybės ir saugumo tikrinimui bus naudojamas SonarQube.
  • 6Sistemos išeities kodų laikymui turi būti naudojama Užsakovo kodo saugykla – GitLab.
  • 7Sistemos kokybės užtikrinimo ir diegimo procesams turi būti naudojama Pirkėjo kodo saugykla – GitLab.
  • 8Pirkėjas numato, Gitlab platformoje, vykdyti automatines ir rankines programinės įrangos išeities kodo analizės peržiūros procedūras (Code Review), Teikėjas įsipareigoja į jas atsižvelgti ir atlikti pakeitimus pagal Pirkėjo pateiktas pastabas.
  • 9Su Pirkėju turi būti suderinti ir naudojami statinio kodo analizės įrankiai, kurie užtikrintų kodo atitiktį pagal gerąsias praktikas, teisingą sintaksės formavimą, pažeidžiamumą ir kt. Šiuos pasirinktus įrankius Pirkėjas turi galėti integruoti į automatinius kodo kokybės užtikrinimo procesus (Continues Integration) Gitlab platformoje.
  • 10Sistema turi būti kuriama taip, kad atitiktų „kodas paremtu testu“ (Test-Driven Development) principą.
  • 11Pirkėjui turi būti pateikiamos periodinės atitikties ataskaitos (Code Coverage Reports), o Teikėjas įsipareigoja pašalinti Perkančiosios organizacijos pateiktas pastabas. Šių ataskaitų pateikimą, Pirkėjas turi galėti integruoti į procesus (Continues integration) Gitlab platformoje.
  • 12Sistemos kūrimui ir jos komponentų kūrimui turi būti naudojamas pasirinktas Spring, Spring Boot, Symfony ar lygiavertis žiniatinklių ir (ar) mikroservisų kūrimo karkasas.
  • 13Sistema ir jos komponentai turi gebėti veikti su bendru duomenų sluoksniu (Persistent storage).
  • 14Sistema ir jos komponentai turi gebėti veikti su bendru atminties sluoksniu (RAM).
  • 15Integracijos turi būti realizuotos laikantis gerųjų praktikų, paremtų „Priklausomybės valdymo” principais (Dependency Manager), kai integraciniai paketai kuriami ir plėtojami kaip atskiros programinės įrangos bibliotekos ir diegiamos panaudojant priklausomybės diegimo įrankius kaip: Maven, Composer ar lygiaverčius.
  • 16Tiekėjas, suderinęs su Perkančiąja organizacija, turi naudoti naujai kuriamai PĮ jos kūrimo dieną esamas naujausias programinių paketų (pvz. Microsoft Office 2019 WordML technologijos naudojimui), bibliotekų (pvz. jQuery v3.7.1, jQuery.min, Bootstrap ir kt.), programavimo kalbų, jų kompiliatorių bei interpretatorių versijas (pvz., JDK21, .NET 4.8, .NET Core, PHP 8.0).
  • 17Tiekėjas Sistemos kūrimui turi naudoti naujausias stabilias programinės įrangos versijas ir jos pataisymus (Patch / Fix).
  • 18Neturi būti naudojamos programinių komponentų versijos, kurios yra testavimo stadijoje arba yra oficialiai programinės įrangos gamintojo paskelbta, kad programinė įranga nuo tam tikros datos nebebus palaikoma, tobulinama ir / ar vystoma (End-of-life product).

Bendrieji paslaugų teikimo reikalavimai

  • 1Tiekėjas pats pasirūpina Paslaugoms teikti reikalingomis priemonėmis ir technine įranga.
  • 2Tiekėjas neturi naudoti trečiųjų šalių komponentų, kurie yra nauji, niekada nenaudoti projektuose, Alpha ar Beta testavimo etapuose, reikalauja papildomų licencijų veikimui.
  • 3Tiekėjas įsipareigoja Perkančiosios organizacijos atstovams teikti konsultacijas, susijusias su Pirkimo objektu, raštu bei žodžiu visą Sutarties galiojimo laikotarpį.
  • 4Prieš suteikiant prieigą prie Perkančiosios organizacijos tvarkomų asmens duomenų, Tiekėjas privalės Perkančiajai organizacijai pateikti už asmens duomenų apsaugą atsakingo asmens vardą, pavardę ir kontaktinius duomenis (telefono numerį, el. pašto adresą).
  • 5Tiekėjas turės pasirašyti susitarimą dėl asmens duomenų tvarkymo, kaip tai nustatyta 2016 m. balandžio 27 d. Europos Parlamento ir Tarybos reglamento (ES) 2016/679 dėl fizinių asmenų apsaugos tvarkant asmens duomenis ir dėl laisvo tokių duomenų judėjimo ir kuriuo panaikinama Direktyva 95/46/EB (Bendrasis duomenų apsaugos reglamentas) 28 straipsnio 3 dalyje, kuriame turės būti nustatytas asmens duomenų tvarkymo dalykas ir trukmė, duomenų tvarkymo pobūdis ir tikslas, asmens duomenų rūšis ir duomenų subjektų kategorijos bei Registrų centro prievolės ir teisės.
  • 6Tiekėjas turi užtikrinti, kad Paslaugos atitinka Kibernetinio saugumo reikalavimų apraše, patvirtintame Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimu Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo“, nurodytus reikalavimus.
  • 7Teikėjo specialistams bus suteikta prieiga prie Pirkėjo aplikacijų: JIRA, CONFLUENCE.
  • 8Teikėjo specialistams aplikacijų programuotojams bus suteikta prieiga prie Pirkėjo GIT repozitoriumo Pirkimo objekto programinės įrangos išeities tekstų versijų valdymui, Pirkėjo infrastruktūros kūrimo aplinkoje (DEV) Pirkimo objekto vykdymui dedikuotų serverių (nesuteikiant administratoriaus teisių) ir reikalingų DB schemų.
  • 9Pagal poreikį, Pirkėjas suteiks saugią nuotolinę prieigą – dedikuotą virtualią darbo vietą (VDI), per kurią Teikėjo specialistai pasieks Pirkėjo išteklius reikalingus Paslaugų teikimui.
  • 10Pagal poreikį, Pirkėjas galės suteikti Teikėjo specialistų kompiuterinėms darbo vietoms saugią nuotolinę VPN prieigą prie jiems dedikuotų išteklių reikalingų Pirkimo objekto vykdymui.
  • 11Pirma užduotis JIRA turi būti pateikiama ne vėliau kaip per 1 (vieną) mėn. nuo Sutarties pasirašymo dienos.
  • 12Tiekėjas turi paskirti atsakingus už konsultacinių paslaugų teikimą asmenis, kurie turi būti pasiekiami registruojant užduotis Pirkėjo naudojamoje informacinių technologijų užduočių valdymo ir tvarkymo sistemoje JIRA, nurodytu telefono numeriu ir elektroniniu paštu.
  • 13Pirkėjo specialistų konsultavimas turi būti atliekamas Pirkėjo JIRA priemonėmis, telefonu ar MS Teams platformoje, elektroniniu paštu bei specialistų darbo vietoje darbo valandomis: darbo dienomis nuo 8:00 iki 17:00 val., penktadieniais 8:00 iki 15:45.
  • 14Laimėjusio Teikėjo specialistai, kurie per pastaruosius 5 metus nedirbo su modernizuojama Sistema ar jos dalimi, per su Užsakovu suderintą laikotarpį (ne ilgesnį kaip 1 mėnuo) turės susipažinti su Sistema tokiu lygiu, kuris užtikrintų bendrą komandos supratimą apie jos veikimą ir pagrindinius komponentus.
  • 15Teikėjas užtikrina, kad asmuo, vykdysiantis Sutarties Techninės dalies įgyvendinimą pasirašytų Pirkėjo pateiktą Konfidencialumo pasižadėjimą.
  • 16Per 20 darbo dienų nuo Sutarties įsigaliojimo Teikėjas turi surengti įvadinį susitikimą su Registrų centru bei pateikti derinimui ir pristatyti Paslaugų teikimo reglamentą, apimantį tokias pagrindines dalis: paslaugų atlikimo ir pateikčių pateikimo terminai; paslaugų teikimo organizacinė struktūra; komunikacijos tvarka; kita svarbi informacija.
  • 17Teikėjas privalo prieš priduodamas Sistemos pakeitimus Pirkėjui pateikti galutines dokumentacijos ir Sistemos išeities kodo versijas, jeigu jos buvo pakeistos nuo paskutinio pridavimo.
  • 18Autorių turtinės teisės į pagal užsakymą sukurtą programinę įrangą ir parengtus projektinius dokumentus, įskaitant teisę neribotą laiką ir be papildomo atlygio naudoti, kopijuoti, modifikuoti, plėtoti, perkelti į kitą technologinę platformą, naudoti ir keisti pradinį kodą, perduodamos Pirkėjui.
  • 19Kartu su kompiuterine programa Pirkėjui perduodamas ir programos išeitinis kodas.
  • 20Teikėjas neturi teisės atskleisti jokios su paslaugų teikimu susijusios informacijos trečiosioms šalims be Pirkėjo raštiško leidimo arba jei to reikalauja įstatymai.

Saugumo ir duomenų apsaugos reikalavimai

  • 1Duomenų sauga turi būti užtikrinta vadovaujantis Sistemos duomenų saugos nuostatais, asmens duomenų apsauga turi būti užtikrinta Lietuvos Respublikos asmens duomenų teisinės apsaugos įstatymu ir 2016 m. balandžio 27 d. Europos Parlamento ir Tarybos reglamentu (ES) 2016/679.
  • 2Teikėjas turi laikytis ir užtikrinti, kad Paslaugos atitiktų Lietuvos Respublikos valstybės informacinių išteklių valdymo įstatyme, Lietuvos Respublikos kibernetinio saugumo įstatyme, Bendrųjų elektroninės informacijos saugos reikalavimų apraše, Organizacinių ir techninių kibernetinio saugumo reikalavimų apraše nustatytus saugumo reikalavimus ne žemesnės negu II kategorijos valstybės informacinei sistemai.
  • 3Sistemoje saugomi duomenys turi būti apsaugoti nuo nesankcionuoto priėjimo, naudojimo, pakeitimo, atskleidimo, sunaikinimo ar praradimo.
  • 4Asmens duomenys perduodami viešais duomenų perdavimo kanalais turi būti šifruojami.
  • 5Draudžiama fizinių asmenų asmens kodus skelbti viešai.
  • 6Sistema turi užtikrinti korektišką avarinių situacijų valdymą, informuojant naudotojus ar informacinę sistemą apie susidariusią situaciją ir galimus tolimesnius veiksmus.
  • 7Turi būti įgyvendintos Sistemos naudotojų veiksmų, atliktų per sąsają, veiklos atsekamumo priemonės.
  • 8Tikslūs audito įrašų darymo momentai turi būti identifikuoti detalios analizės metu kartu su Pirkėju, siekiant išvengti perteklinės audito informacijos kaupimo.
  • 9Sutrikus sistemų darbui, sistemos naudotojams turi būti pateikiami atitinkami pranešimai.
  • 10Sistema turi būti apsaugota nuo šių grėsmių: neautentifikuotos prieigos, nesankcionuoto naudotojo sesijos perėmimo, nesankcionuoto duomenų perėmimo ar jų įterpimo, žalingo kodo įterpimo (Injection, XSS), kitų saugumo pažeidimų, kurių sąrašas skelbiamas OWASP interneto svetainėje.
  • 11Teikėjas, kurdamas programinę įrangą, turi vadovautis visuotinai pripažintais saugaus kodavimo standartais ir gerąja praktika (OWASP Secure Coding Practices ar lygiaverte).
  • 12Saugumo patikrinimai (grėsmių modeliavimai, išeities kodo pažiūros ir kt.) turi būti vykdomi kiekviename programinės įrangos kūrimo etape, vadovaujantis Elektroninių paslaugų kūrimo metodika, nustatančia reikalavimus atsparumo įsilaužimui testavimui.
  • 13Sistemos teikiamų žiniatinklio paslaugų sauga turi būti vykdoma vadovaujantis WS-S (Web Services Security) standarto reikalavimais.
  • 14Teikėjas turi naudoti Pirkėjo pateiktus reikiamus sertifikatus, skirtus užtikrinti žiniatinklio paslaugų saugą.
  • 15Teikėjas turės atlikti Sistemos atitikties vertinimą pagal teisės aktus ir pateikti tokio vertinimo ataskaitą, kuri turi būti suderinta su RC.
  • 16Informacinių išteklių vystymo ir priežiūros saugumas (saugus kodavimas) turi būti užtikrintas, kaip reikalaujama Lietuvos standartuose LST EN ISO/IEC 27001 ir LST EN ISO/IEC 27002.
  • 17Duomenų sauga turi būti užtikrinama: užtikrinant duomenų vientisumą, prieinamumą ir konfidencialumą; registruojant Sistemos naudotojų atliekamus veiksmus su duomenimis; sukuriant priemones, sudarančias galimybes Sistemos administratoriui patikrinti Sistemos naudotojų veiksmus; numatant apsaugos nuo atsitiktinio duomenų ištrynimo priemones bei duomenų trynimo veiksmo tvirtinimą keliems naudotojams („keturių akių principas“); darbui su komponentais Sistemos naudotojus suskirstant į grupes pagal duomenų tvarkymo pobūdį, kai kuriems iš jų suteikiant specialiąsias teises (roles) atlikti tam tikrus tvarkymo veiksmus; saugoma informacija negali būti ištrinta jokiais kitais būdais ar aplinkybėmis, išskyrus analizės ir projektavimo etapuose numatytais atvejais; Teikėjas turi suderinti failų formatus, kuriuos leidžiama įkelti į Sistemą, ir suderinti juos su RC (pvz., neturi būti leidžiama prisegti potencialiai nesaugių, galinčių automatiškai pasileisti failų).
  • 18Teikėjas privalo vadovautis pripažintomis saugaus programinės įrangos kūrimo metodikomis, tokiomis kaip ISO/IEC 27034-1 arba lygiavertėmis.
  • 19Teikėjas privalo užtikrinti, kad visi programinės įrangos kūrime dalyvaujantys darbuotojai susipažinę su saugaus programinės įrangos kūrimo metodikomis.
  • 20Teikėjas privalo pateikti visų, sistemoje naudojamų trečių šalių komponentų sąrašą.
  • 21Teikėjas privalo imtis tinkamų veiksmų užtikrinant, kad trečių šalių komponentai atitinka RC saugumo reikalavimus.
  • 22Teikėjas turi atlikti reikiamus Sistemos programavimo ir / ar konfigūravimo darbus, atsižvelgiant į RC atstovų atliktų atsparumo įsilaužimams testavimų rezultatus, kad prieš pradedant eksploatuoti Sistema būtų pašalinti visi nustatyti svarbūs saugumo pažeidžiamumai.
  • 23Sistemoje draudžiama bet kokia neautorizuota ar nedokumentuota nuotolinė ar lokali prieiga/ paskyros ar bet koks slaptas (nedokumentuotas) funkcionalumas galintis pažeisti sistemos saugumą.
  • 24Teikėjas privalo pateikti detalias sistemos ir platformos (OS, DBMS, Middleware) saugumo konfigūravimo instrukcijas.
  • 25Sistemos Teikėjas privalo pateikti sistemos funkcionavimui būtinų platformos komponentų, sisteminių paslaugų, prievadų sąrašą. Visi nebūtini Sistemos funkcionalumui komponentai turi būti deaktyvuoti prieš pradedant sistemos eksploataciją.
  • 26Duomenų srautai tarp skirtingų lygių turi būti dokumentuoti, nurodant reikalingus komunikacijai prievadus ir protokolus, bei ribojami ugniasienių.
  • 27Sistemos išorinis portalas turi būti atskirame nuo Sistemos vidinių posistemių tinklo segmente.

Dokumentai6

  • Techninės specifikacijos priedas RPO (projektas).docx
  • Tiekėjų kvalifikacijos reikalavimai (projektas).docx
  • Pasiūlymo vertinimo kriterijai ir sąlygos (projektas).docx
  • Kvietimas dalyvauti RDK.docx
  • 1068_7605809.pdf
  • Techninė specifikacija (projektas).docx
tendis.lt · Sukurta recodin.lt