Internetinės svetainės priežiūros, vystymo ir konsultavimo paslaugų pirkimas
Išanalizuota
AB "Amber Grid"
Rinkos konsultacijaCPV: 72000000 - IT paslaugos: konsultavimas, programinės įrangos kūrimas, internetas ir aptarnavimo paslaugos
ID: 78620222026-05-14 10:09
Atidaryti CVP ISAprašymas
AB „Amber Grid“ vykdo internetinės svetainės priežiūros, vystymo ir konsultavimo paslaugų pirkimą. Šios paslaugos apims Sistemos gyvavimo ciklo valdymą, užtikrinant nepertraukiamą veikimą, saugumą ir funkcionalumo plėtrą. Visi darbai bus vykdomi modulių principu, atsižvelgiant į Užsakovo poreikius.
Kvalifikaciniai reikalavimai
- 1Tiekėjas per pastaruosius 3 metus iki tos dienos, kai galimas laimėtojas turės pateikti dokumentus arba per laiką nuo tiekėjo įregistravimo dienos (jeigu tiekėjas vykdė veiklą mažiau nei 3 metus), turi būti įvykdęs arba vykdo bent vieną sutartį, kurios metu buvo sukurta interneto svetainė ir teikiamos palaikymo bei vystymo paslaugos kurios vertė yra ne mažesnė kaip 60 000 Eur be PVM.
- 2Projekto vadovas privalo turėti ne mažesnę kaip 3 metų darbo patirtį informacinių technologijų (IT) srityje.
- 3Programavimo specialistas privalo turėti ne mažesnę kaip 3 metų darbo patirtį IT srityje.
- 4Programavimo specialistas turi būti dalyvavęs bent viename įgyvendintame projekte, kuriame buvo sukurta interneto svetainė naudojant EasyWeb4 turinio valdymo sistemą.
- 5Programavimo specialistas turi turėti kvalifikaciją, reikalingą programuotojui ir tai patvirtinantį sertifikatą.
- 6Tiekėjas turi turėti įdiegtą ir veikiančią kokybės vadybos sistemą pagal ISO 9001:2015 arba lygiavertį standartą informacinių technologijų srityje.
- 7Tiekėjas turi turėti įdiegtą ir veikiančią informacinių technologijų vadybos sistemą pagal ISO 20000-1:2018 arba lygiavertį standartą informacinių technologijų srityje.
- 8Tiekėjas turi turėti įdiegtą ir veikiančią informacijos saugos vadybos sistemą pagal ISO 27001:2022 arba lygiavertį standartą informacinių technologijų srityje.
- 9Tiekėjas turi turėti įdiegtą ir veikiančią aplinkos apsaugos vadybos sistemą pagal ISO 14001:2015 arba lygiavertį standartą informacinių technologijų srityje.
- 10Tiekėjas pareiškia ir garantuoja, kad nei jis, nei jo pasitelkiami subrangovai nėra kilę iš valstybių, kurios kelia grėsmę Lietuvos Respublikos nacionaliniam saugumui.
- 11Griežtai draudžiama naudoti programinės ar techninės įrangos elementus, kurių gamintojai, tiekėjai ar galutiniai naudos gavėjai yra registruoti, valdomi ar kontroliuojami šalyse, kurios yra įtrauktos į LR Vyriausybės patvirtintus nepatikimų ar draudžiamų valstybių sąrašus (įskaitant, bet neapsiribojant, Rusijos Federaciją, Baltarusijos Respubliką ir Kinijos Liaudies Respubliką).
- 12Sutartis įsigalioja tik po to, kai kompetentinga LR Vyriausybės komisija priima sprendimą, kad Tiekėjas ir jo ketinamas sudaryti sandoris nekelia grėsmės nacionalinio saugumo interesams.
Techniniai reikalavimai
Prieigos valdymas
- 1Prieiga suteikiama vadovaujantis principu „Būtina darbui“. Kiekvienas naudotojas ar administratorius privalo būti unikaliai atpažįstamas. Bendrinės (pvz., admin, root) ar svečio (Guest) paskyros privalo būti išjungtos.
- 2Administratoriaus funkcijos atliekamos naudojant dedikuotą paskyrą, kuri negali būti naudojama kasdienėms funkcijoms (interneto naršymui, el. paštui).
- 3Sistemoje draudžiama saugoti slaptažodžius atviru tekstu. Visi slaptažodžiai privalo būti maišomi naudojant saugius, lėtus algoritmus (pvz., Argon2, bcrypt, PBKDF2 ar lygiaverčius).
- 4Prieš eksploatavimą visi standartiniai (gamintojo) slaptažodžiai privalo būti pakeisti. Laikini slaptažodžiai perduodami tik saugiais, šifruotais kanalais, atskiriant juos nuo prisijungimo vardo.
- 5Sistema privalo užtikrinti galimybę naudoti dviejų faktorių autentifikaciją (MFA) visiems privilegijuotiems prisijungimams.
- 6Tiekėjas, teikdamas paslaugas nuotoliniu būdu, privalo naudoti tik Užsakovo patvirtintus saugaus prisijungimo kanalus (pvz., VPN su MFA).
- 7Nuotolinė administratoriaus prieiga prie YSII komponentų yra griežtai ribojama ir vykdoma tik per Užsakovo valdomą privilegijuotų naudotojų prieigos valdymo sprendimą (PAM), užtikrinant sesijų įrašymą.
- 8Prieigą prie Sistemos gali turėti tik su Užsakovu iš anksto suderintas Tiekėjo personalo sąrašas.
- 9Jungiantis prie Sistemos naudojama Tiekėjo kompiuterinė įranga atitiktų šiuos reikalavimus: įdiegta, veikianti ir reguliariai atnaujinama apsaugos programinė įranga (Endpoint Protection / Antivirus); operacinė sistema yra palaikoma gamintojo ir turi įdiegtus naujausius saugumo atnaujinimus; įjungta ugniasienė (Firewall); naudojami tik saugūs duomenų perdavimo tinklai.
Saugumo reikalavimai
- 1Tiekėjas, identifikavęs Sistemos saugumo pažeidžiamumą, privalo nedelsdamas informuoti Užsakovą, nelaukdamas, kol pažeidžiamumas bus pašalintas.
- 2Jeigu pažeidžiamumo pašalinimo priemonės dar nėra prieinamos, Tiekėjas privalo pateikti preliminarų jo pašalinimo grafiką ir numatomas technines rizikos mažinimo priemones.
- 3Saugumo pažeidžiamumų šalinimo terminai nustatomi pagal jų kritiškumo lygį, vertinamą pagal CVSS v4.0 (ar naujesnę versiją), vadovaujantis oficialiais nvd.nist.gov arba cve.org šaltiniais:
- 4 - KRITINIS (9.0 – 10.0): 2 darbo dienos (rizikos mažinimo planas pateikiamas per 24 val.) Sistemoms pasiekiamoms iš interneto.
- 5 - AUKŠTAS (7.0 – 8.9): 7 kalendorinės dienos Sistemoms pasiekiamoms iš interneto.
- 6 - VIDUTINIS (4.0 – 6.9): 30 kalendorinių dienų Sistemoms pasiekiamoms iš interneto.
- 7 - ŽEMAS (0.1 – 3.9): 180 kalendorinių dienų Sistemoms pasiekiamoms iš interneto.
- 8Saugos atnaujinimų diegimo laikų skaičiavimas pradedamas nuo gamintojo pataisos viešo išleidimo datos arba nuo informacijos gavimo dienos, jei tai įvyksta vėliau.
- 9Užsakovas pasilieka teisę savo iniciatyva ir lėšomis bet kuriuo metu atlikti Sistemos saugumo vertinimą (pažeidžiamumų skenavimą ar penetracijos testus). Tiekėjas privalo netrukdyti tokiems veiksmams ir bendradarbiauti šalinant nustatytus trūkumus.
- 10Tiekėjui griežtai draudžiama be išankstinio raštiško Užsakovo Prevencijos skyriaus leidimo atlikti Sistemos ar Užsakovo tinklo pažeidžiamumų skenavimą, stebėti duomenų srautus ar naudoti kitas atakas imituojančias priemones.
- 11Tiekėjas apie bet kokį Kibernetinį incidentą ar jo grėsmę, galinčią paveikti Užsakovo informacinę infrastruktūrą ar duomenis, privalo pranešti Užsakovui nedelsiant, bet ne vėliau kaip per 2 valandas nuo jo fiksavimo.
- 12Ne vėliau kaip per 24 valandas nuo sužinojimo, Tiekėjas privalo pateikti pradinį Incidento vertinimą, o per 72 valandas – išsamią ataskaitą.
- 13Pranešimai apie Kibernetinius incidentus teikiami nedelsiant (ne vėliau kaip per 2 val.) telefonu ir el. paštu.
- 14Priklausomai nuo Sistemos klasifikacijos (nurodytos Priede Nr. 1), Paslaugoms taikomi šie reikalavimai: Esminė infrastruktūra (YSII) – Tiekėjas privalo vadovautis LR Kibernetinio saugumo įstatymu ir „Organizacinių ir techninių kibernetinio saugumo reikalavimų... aprašu“; Komercinė infrastruktūra (KKII) – Tiekėjas privalo vadovautis Energetikos ministro patvirtintais saugos reikalavimais (jei taikoma Užsakovo sektoriui) bei LST ISO/IEC 27001 standarto reikalavimais.
- 15Perkeliant programinę įrangą į Gamybinę aplinką (PROD), Tiekėjas privalo užtikrinti, kad kode nebūtų palikta derinimo (Debug) kodo, komentarų su jautria informacija, pavyzdinių duomenų ar testinių skriptų, bei klaidų pranešimų, kurie galutiniam naudotojui atvaizduotų techninę informaciją.
- 16Kuriant ar modifikuojant sprendimus, privaloma vadovautis OWASP Top 10, CWE/SANS Top 25 bei CIS Controls rekomendacijomis.
- 17Tiekėjas privalo įgyvendinti ISO/IEC 27001:2022 (Saugaus kodo rašymas) reikalavimus: užtikrinti griežtą įvesties validaciją, saugų klaidų apdorojimą ir mažiausių privilegijų principo taikymą kodo lygmenyje.
- 18Tiekėjas privalo naudoti programinės įrangos sudėties analizės (SCA) įrankius, siekiant užtikrinti, kad naudojamos atvirojo kodo bibliotekos neturi žinomų CVE pažeidžiamumų.
- 19Visi naudojami baziniai komponentai turi būti naujausių stabilių versijų arba turėti ilgalaikį palaikymą (LTS). Gamintojui išleidus naujesnę versiją, ji turi būti ištestuota ir sudiegta ne vėliau kaip per 6 mėnesius po išleidimo datos (jei įsigytas atitinkamas palaikymo Modulis).
- 20Tiekėjas užtikrina, kad Paslaugas teikiantys darbuotojai būtų supažindinti su Užsakovo „Neskelbtinos informacijos apsaugos politika“ bei šiais Techninės specifikacijos reikalavimais.
- 21Tiekėjas privalo turėti patvirtintus vidinius Kibernetinių incidentų valdymo ir Veiklos tęstinumo planus, kuriuos, Užsakovui pareikalavus, privalo pateikti peržiūrai.
- 22Produkte (Sistemoje) griežtai draudžiama palikti: nedokumentuotas vartotojo paskyras; kriptografinius raktus ar slaptažodžius, kurių Užsakovas negalėtų savarankiškai pakeisti; bet kokias „galinių durų“ (Backdoor) funkcijas.
- 23Tiekėjas sutartimis privalo įpareigoti visus savo subrangovus laikytis tokių pačių kibernetinio saugumo, NIS2 incidentų raportavimo ir audito reikalavimų, kokie numatyti šioje Sutartyje.
- 24Tais atvejais, kai Paslaugų teikimui būtinas fizinis Tiekėjo darbuotojų atvykimas į Užsakovo patalpas, privaloma laikytis Užsakovo nustatytų fizinio saugumo taisyklių: patekimas tik su vardiniais leidimais; draudimas įsinešti pavojingus daiktus ar atvykti apsvaigus; griežtas draudimas filmuoti ar fotografuoti be leidimo.
- 25Jei Sistema Priede Nr. 1 klasifikuojama kaip Ypatingos svarbos informacinė infrastruktūra (YSII): Esminė infrastruktūra negali turėti tiesioginės nuotolinės prieigos iš viešųjų duomenų tinklų (interneto), nebent naudojami specializuoti saugumo vartai (Gateways / VPN); Komponentų administravimui Tiekėjas privalo naudoti dedikuotą techninę įrangą (darbo stotis), kurioje nenaudojamos el. pašto programos ir kuri neturi tiesioginės prieigos prie interneto bendrojo naršymo tikslais.
Auditas ir atskaitomybė
- 1Užsakovas pasilieka teisę, iš anksto įspėjęs, atlikti Tiekėjo taikomų saugumo priemonių (susijusių su šia Sutartimi) auditą.
- 2Tiekėjas privalo leisti atlikti savo operacijų auditą savo patalpose ir visapusiškai bendradarbiauti, pateikdamas reikalingą informaciją Užsakovo įgaliotiems asmenims ar nepriklausomiems išorės auditoriams.
Perkamų paslaugų apimtis
- 1Perkamas 2 MODULIS: Techninis palaikymas (SLA) – fiksuotas mėnesinis mokestis už Sistemos pasiekiamumą ir Incidentų valdymą.
- 2Perkamas 3 MODULIS: Vystymo paslaugos – maksimalus 1100 valandų kiekis per Sutarties laikotarpį.
- 3Perkamas 4 MODULIS: Konsultacijos / Užklausos – maksimalus 200 valandų kiekis per Sutarties laikotarpį.
Sutarties pabaigos reikalavimai
- 1Visos Tiekėjo personalo prieigos prie Sistemos panaikinamos per 24 valandas po Sutarties pabaigos.
- 2Pasibaigus Sutarčiai, Tiekėjas saugiai perduoda Užsakovui visus sukauptus duomenis (suderintu formatu) ir po perdavimo negrįžtamai ištrina visas kopijas iš savo sistemų, pateikdamas tai patvirtinantį aktą.
- 3Likus ne mažiau kaip 60 dienų iki Sutarties pabaigos, Tiekėjas privalo inicijuoti formalizuotą Žinių perdavimo procesą, apimantį atnaujintos architektūros dokumentacijos, kodo repozitorijų ir konfigūracijų perdavimą Užsakovui arba jo nurodytam naujam paslaugų teikėjui.
Duomenų tvarkymas ir saugojimas
- 1Duomenys privalo būti šifruojami tiek juos saugant (Encryption at Rest, pvz., AES-256 ar lygiavertis standartas), tiek perduodant (Encryption in Transit, pvz., TLS 1.3).
- 2Visi Užsakovo duomenys saugomi ir tvarkomi tik ES / EEE teritorijoje.
- 3Tiekėjui draudžiama naudoti asmenines el. pašto dėžutes ar asmenines debesijos paslaugas Užsakovo informacijai tvarkyti.
- 4Užsakovo duomenys nebus perduodami už EEE ribų, nebent tai aiškiai numatyta Sutartyje ir įgyvendintas BDAR V skyriaus mechanizmas.
- 5Prieiga prie Neskelbtinos informacijos Tiekėjo personalui suteikiama tik pasirašius Konfidencialumo susitarimą (NDA).
Sistemos aprašymas ir kontekstas
- 1Sistemos pavadinimas: WEB internetinė svetainė.
- 2Sistemos klasifikacija: Komercinė informacinė infrastruktūra (KKII).
- 3Sistemos paskirtis: Užtikrinti nepertraukiamą Bendrovės reprezentaciją skaitmeninėje erdvėje, teikti aktualią informaciją apie Bendrovės veiklą klientams partneriams ir visuomenei.
- 4Technologinė platforma (Backend): php, apache, mySQL, pdo_mysql, EasyWeb4, MS SQL sprendiniai (integracijai), vandenilio koridorius internetinė svetainė (php, mySQL).
- 5Yra TEST ir PROD aplinkos.
- 6Technologinė platforma (Frontend): HTML, CSS, JavaScript, Microsoft Power BI Embedded.
- 7Duomenų bazė (DB): mySQL ir Microsoft SQL Server Express (skirta integracijos duomenų paruošimui).
- 8Duomenų apimtis: 200 GB.
- 9Kodo apimtis / Architektūra: Architektūros tipas Monolitas.
- 10Integracijos: Power BI (Embeded), Amberflows (gamtinių dujų apskaitos sistema REST API).
- 11Infrastruktūra (Hostingas): Įmonės MS Azure ir Hostinger.com platformos.
- 12Dokumentacijos būklė: Bendrinė, architektūrinė.
- 13Padengimas testais: Nėra.
- 14Į pirkimo objektą neįeina techninės infrastruktūros (serverių, duomenų saugyklų, tinklo įrangos, operacinių sistemų) nuoma ar fizinis patiekimas.
- 15Tiekėjas privalo užtikrinti visišką Sistemos funkcionalumą ir suderinamumą su Užsakovo suteikta infrastruktūra, atitinkančia minimalius reikalavimus.
- 16Įvykus sutrikimui, Tiekėjas atlieka pirminę diagnostiką ir pateikia techninius įrodymus, jei teigia, kad sutrikimas kilo dėl infrastruktūros.
- 17Tiekėjas privalo bendradarbiauti su Užsakovo infrastruktūros administratoriais ar trečiaisiais asmenimis, teikdamas aiškias technines rekomendacijas dėl bazinės programinės įrangos konfigūravimo.
- 18Apie būtinus bazinės įrangos pokyčius Tiekėjas privalo informuoti Užsakovą ne vėliau kaip prieš 10 darbo dienų iki diegimo į Testavimo aplinką.
- 19Paslaugos teikiamos nuotoliniu būdu, naudojant tik Užsakovo patvirtintą saugų VPN ryšį ir dviejų faktorių autentifikaciją (MFA).
- 20Jei Sistema klasifikuojama kaip YSII, nuotolinė prieiga administratoriaus teisėmis vykdoma tik per Užsakovo privilegijuotų naudotojų prieigos valdymo (PAM) sistemą.
SLA ir veiklos tęstinumo rodikliai
- 1Paslaugų teikimo laikas: I–IV 8:00–17:00, V 8:00–15:45 (Lietuvos laiku).
- 2SLA skaičiavimas: P1, P2 lygio ir Kibernetiniams incidentams – 24/7/365; P3 ir P4 lygio incidentams – tik Darbo valandomis.
- 3Kibernetinis incidentas: reakcijos laikas – maks. 2 val., veiklos atstatymas / laikinasis sprendimas – nedelsiant (Sistemos / tinklo izoliavimas), galutinis išsprendimas – pagal TS 8.1.4 p.
- 4P1 (Kritinis) incidentas: reakcijos laikas – 2 d. val., veiklos atstatymas / laikinasis sprendimas – 4 d. val., galutinis išsprendimas – 6 d. val.
- 5P2 (Aukštas) incidentas: reakcijos laikas – 4 d. val., veiklos atstatymas / laikinasis sprendimas – 8 d. val., galutinis išsprendimas – 28 d.v.
- 6P3 (Vidutinis) incidentas: reakcijos laikas – 8 d. val., veiklos atstatymas / laikinasis sprendimas – 24 d. val., galutinis išsprendimas – pagal susitarimą, bet ne ilgiau nei 7 d.d.
- 7P4 (Žemas) incidentas: reakcijos laikas – 8 val., galutinis išsprendimas – pagal susitarimą, bet ne ilgiau nei 30 d.d.
- 8RTO (Veiklos atkūrimo laikas): 8 val. – maksimalus laikas Sistemai visiškai atstatyti po kritinės avarijos (atkuriant iš atsarginių kopijų).
- 9RPO (Duomenų atkūrimo taškas): 24 val. – maksimalus leistinas duomenų praradimas (priklauso nuo infrastruktūros atsarginių kopijų darymo dažnumo).
Bendrieji paslaugų valdymo reikalavimai
- 1Paslaugų teikimą organizuoti vadovaujantis pripažintomis IT paslaugų valdymo metodologijomis (pvz., ITIL, ISO/IEC 20000 arba lygiaverčiais standartais).
- 2Užtikrinti šių procesų veiksmingumą: Incidentų valdymas, Paslaugų užklausų valdymas, Problemų valdymas, Pakeitimų valdymas.
- 3Suteikti Užsakovui prieigą prie elektroninės užklausų registravimo sistemos (Pagalbos tarnybos sistemos), kuri turi užtikrinti unikalų kreipinio identifikatorių (ID), statusų sekimą realiuoju laiku ir SLA laiko kontrolę.
- 4Draudžiama vykdyti apmokestinamus darbus, jei jie nėra oficialiai užregistruoti Pagalbos tarnyboje, išskyrus atvejus, kai tokie darbai atliekami pagal Šalių pasirašytą Užsakymą ar kitą Sutarties Bendrosiose sąlygose numatytą dokumentą.
- 5Sutarties pabaigoje perduoti Užsakovui visą kreipinių istoriją ir ar duomenų bazės išrašą atviraisiais, mašininiu būdu nuskaitomais formatais (pvz., CSV, JSON, XML) archyvavimui.
- 6Jei naudojama Tiekėjo Pagalbos tarnybos sistema, prisijungimas prie jos vyktų tik per saugų protokolą (ne žemesnį nei TLS 1.2) ir būtų privalomai apsaugotas dviejų faktorių autentifikacija (MFA).
- 7Tiekėjo Pagalbos tarnybos sistema ir joje esantys Užsakovo duomenys privalo būti fiziškai ir logiškai dislokuoti tik Europos ekonominės erdvės (EEE) teritorijoje.
- 8Sistemoje griežtai draudžiama saugoti nešifruotus slaptažodžius arba konfidencialią Ypatingos svarbos informacinės infrastruktūros (YSII) architektūros informaciją be išankstinio rašytinio Užsakovo sutikimo.
- 9Užsakovui pareikalavus, užtikrinti Pagalbos tarnybos sistemos integraciją su Užsakovo naudojama ITSM sistema per standartizuotas programines sąsajas (pvz., REST API arba Webhooks), užtikrinant automatinį dvipusį Incidentų, Paslaugų užklausų, jų statusų kaitos, komentarų ir priedų sinchronizavimą realiuoju laiku.
- 10Integraciniai duomenų mainai privalo būti šifruojami, o autentifikacijai naudojami saugūs metodai (pvz., OAuth 2.0 arba rotuojami API raktai / Tokens), atitinkantys YSII saugumo standartus.
- 11Jeigu Tiekėjo naudojama ITSM sistema neturi techninių galimybių tokiai integracijai (neturi atviro API), Tiekėjas privalo be jokių išlygų ir papildomų mokesčių tiesiogiai naudotis Užsakovo ITSM sistema.
- 12Griežtai laikytis aplinkų atskyrimo principo: Kūrimo aplinka (DEV), Testavimo aplinka (UAT), Gamybinė aplinka (PROD).
- 13Testavimo aplinkoje naudoti tik sintetinius (dirbtinai sugeneruotus) duomenis. Gamybinių (PROD) duomenų ir realių YSII konfigūracijų naudojimas testavimo aplinkose yra draudžiamas.
- 14Jei testavimui neišvengiamai būtini realūs duomenys, Tiekėjas privalo taikyti negrįžtamas duomenų maskavimo arba pseudonimizavimo technologijas, atitinkančias ISO/IEC 27001:2022 reikalavimus ir BDAR nuostatas, bei gauti išankstinį rašytinį Užsakovo atsakingo asmens leidimą.
- 15Bet kokie tiesioginiai pakeitimai Gamybinėje aplinkoje (neatlikus testavimo UAT aplinkoje) galimi tik šalinant kritinius Incidentus (SLA P1 lygis) ir tik gavus Užsakovo rašytinį patvirtinimą.
- 16Atlikus pakeitimą Gamybinėje aplinkoje, Tiekėjas privalo nedelsiant (ne vėliau kaip per 1 darbo dieną) atlikti pakeitimų sinchronizavimą atgal į Kūrimo (DEV) bei Testavimo (UAT) aplinkas, užtikrindamas versijų vientisumą.
- 17Kiekvienas diegimas į Gamybinę aplinką privalo turėti iš anksto parengtą ir patikrintą atkūrimo planą, leidžiantį grįžti prie paskutinės stabilios versijos, jei diegimas nepavyktų.
- 18Užsakovui pateikus Nuolatinės integracijos ir nuolatinio diegimo (CI/CD) infrastruktūrą, Tiekėjas įsipareigoja bendradarbiauti ir savo diegimo procesus (įskaitant testavimo automatizavimą ir automatizuotą grįžimą į pradinę būseną) pritaikyti prie Užsakovo konvejerių.
- 19Visas Sistemos kodas būtų reguliariai, ne rečiau kaip kartą per mėnesį (vykdant Vystymo darbus), sinchronizuojamas (replikuojamas) į Užsakovo kontroliuojamą versijų kontrolės sistemą („Azure DevOps Git“ ar kitą Užsakovo nurodytą sistemą).
- 20Užtikrinti, kad visa Sistemos techninė ir vartotojo dokumentacija būtų nuolat atnaujinama ir aktuali.
- 21Atlikus Vystymo darbus (3 Modulis), susijusios dokumentacijos atnaujinimas yra privaloma ir neatsiejama darbų dalis.
- 22Kas mėnesį (arba kitu Šalių sutartu periodiškumu) pateikti Paslaugų teikimo ataskaitą, kurioje nurodoma: Atliktų darbų suvestinė, SLA rodiklių vykdymo (pasiekimo / nepasiekimo) statistika, Panaudotų ir likusių valandų likutis (jei taikoma valandinė kainodara).
- 23Užtikrinti pirkimo dokumentuose nurodytų pagrindinių specialistų dalyvavimą Sutarties vykdyme.
Atsakomybių matrica (RACI) ir eskalavimas
- 1Veiklos tęstinumo prioritetas (angl. Fix First): Įvykus Kritiniam (P1) arba Aukšto prioriteto (P2) lygio Incidentui, Šalys įsipareigoja nedelsiant pradėti Incidento šalinimą, neatsižvelgiant į tai, kieno veiksmai jį sukėlė.
- 2Ginčai dėl Incidento pirminės priežasties ir finansinės atsakomybės sprendžiami tik visiškai atkūrus Paslaugos teikimą.
- 3Tiekėjas, teigdamas, kad sutrikimas kilo ne dėl Sistemos programinės įrangos, privalo pateikti Užsakovui objektyvius techninius įrodymus (veiklos žurnalų išrašus su laiko žymomis, klaidų kodus, stebėsenos grafikus).
- 4Jeigu Šalys nesutaria dėl Incidento priežasties ar atsakomybės, galutinis sprendimas priimamas pasitelkiant nepriklausomą IT ekspertizę.
- 5Eskalavimo procedūra: Jei Šalių atstovai (specialistai) nepriima sprendimo arba Tiekėjas nesilaiko SLA sprendimo laiko terminų, klausimas automatiškai perduodamas aukštesniam valdymo lygmeniui (Šalių vadovams).
- 6Eskalavimas atliekamas Kritinių (P1) ir Kibernetinių incidentų atveju – nedelsiant, bet ne vėliau kaip per 2 valandas nuo SLA termino pažeidimo ar aklavietės fiksavimo; Kitais atvejais – per 3 darbo dienas.
Vystymo paslaugų (3 modulis) reikalavimai
- 1Vystymo paslaugos apima visą programinės įrangos gyvavimo ciklą (SDLC): analizę, sprendimo projektavimą, programavimą, testavimą, diegimą ir dokumentavimą.
- 2Šis modulis netaikomas Incidentų ir Programinių klaidų šalinimui.
- 3Vystymo paslaugos privalo apimti šiuos kokybinius etapus: Analizė (su suderinta technine užduotimi), Projektavimas (architektūros, saugumo reikalavimų įvertinimas), Kūrimas (programavimas, konfigūravimas), Testavimas (funkcinis, nefunkcinis ir saugumo (SAST/DAST) testavimas, testavimo automatizavimas), Diegimas (instaliavimas, konfigūravimas, nulinės prastovos diegimo praktikos).
- 4Atliekant modifikacijas garantuoti, kad visi istoriniai duomenys bus sėkmingai ir be nuostolių migruoti į naujas duomenų bazių struktūras ir bus išlaikytas absoliutus duomenų vientisumas.
- 5Jei Vystymo darbai apima asmens duomenų tvarkymo procesus, sukurti sprendimai privalo turėti realizuotas šias technines funkcijas: Nuasmeninimas, Duomenų eksportas (perkeliamumas), Teisė būti pamirštam, Rolėmis grįsta prieiga (RBAC).
- 6Darbai vykdomi išimtinai tik pagal abipusiai suderintus ir pasirašytus Darbų užsakymo aktus (Užsakymus).
- 7Užsakymo procesas apima: Poreikio pateikimą (Užsakovas), Įvertinimą (Tiekėjas pateikia techninį sprendimą ir valandų sąmatą) ir Įforminimą (Darbų užsakymo akto pasirašymas).
- 8Tiekėjas privalo naudoti Užsakovo nurodytą (arba Šalių suderintą) versijų kontrolės sistemą (pvz., „Git“ pagrindu veikiančią platformą), užtikrinančią kodo pokyčių sekimą, auditą ir atkuriamumą.
- 9Visas kuriamas kodas reguliariai (ne rečiau kaip kartą per savaitę) integruojamas (replikuojamas) į Užsakovo valdomą versijų kontrolės sistemą („Azure DevOps Git“).
- 10Kodo saugykla turi būti fiziškai dislokuota tik EEE (Europos ekonominės erdvės) teritorijoje.
- 11Prieiga prie saugyklos privalo būti apsaugota dviejų faktorių autentifikacija (MFA) ir rolėmis grįsta prieigos kontrole (RBAC).
- 12Privaloma naudoti struktūrizuotą šakų valdymo strategiją (pvz., Git Flow, Trunk-based ar lygiavertę).
- 13Saugykloje (išeities kode) griežtai draudžiama atviru tekstu laikyti slaptažodžius, API raktus, sertifikatus ar kitus jautrius autentifikacijos duomenis; šiems duomenims valdyti privaloma naudoti specializuotus slaptų raktų valdymo sprendimus.
- 14Saugoti bent 3 paskutines stabilias versijas ir užtikrinti techninę galimybę bet kuriuo metu atlikti greitą grįžimą prie ankstesnės versijos (Rollback).
- 15Kiekvienas kodo pakeitimas (angl. Commit) turi būti dokumentuotas aiškiu aprašymu. Kode negali būti palikta komentarų su jautria informacija, derinimo (angl. Debug) kodo ar nenaudojamų (angl. Dead code) bibliotekų.
- 16Visos turtinės teisės į Sutarties vykdymo metu specialiai Užsakovui sukurtus autorinius darbus pereina Užsakovui nuo perdavimo–priėmimo akto pasirašymo momento.
- 17Dokumentavimo darbai yra neatsiejama Vystymo paslaugų dalis, jų kaina privalo būti įskaičiuota į pirminę sąmatą.
- 18Atliekant keitimus, privaloma atnaujinti Techninę dokumentaciją (Architektūros aprašą, Duomenų modelį, Diegimo instrukciją).
- 19Kuriant ar keičiant API, privaloma pateikti Integracinę dokumentaciją: mašininiu būdu nuskaitomą specifikaciją (pvz., OpenAPI 3.0+ failą JSON/YAML formatu), duomenų struktūrų pavyzdžius ir testavimo rinkinį (pvz., „Postman“ kolekciją).
- 20Jei keičiasi vartotojo sąsaja, privaloma atnaujinti Naudotojo dokumentaciją, pateikiant vaizdines instrukcijas ir aprašant dažniausiai pasitaikančias klaidas.
- 21Dokumentacija rengiama lietuvių kalba (nebent Priede Nr. 1 nurodyta anglų k. techninei daliai) ir privalo būti pateikiama elektroniniu redaguojamu formatu.
- 22Visiems Vystymo darbų rezultatams suteikiama 12 (dvylikos) mėnesių garantija nuo Darbų perdavimo–priėmimo akto pasirašymo dienos.
- 23Garantiniu laikotarpiu aptiktos klaidos (neatitikimai techninei užduočiai) taisomos Tiekėjo sąskaita ir nėra apmokestinamos.
- 24Garantijos laikotarpiu (12 mėn.) Tiekėjas privalo užtikrinti sukurto kodo saugumą. Identifikavus pažeidžiamumą, atsiradusį dėl Tiekėjo sukurto kodo ar parinktų bibliotekų, Tiekėjas privalo jį pašalinti savo sąskaita, griežtai laikydamasis TS 8.1 skyriuje nustatytų terminų (pagal CVSS lygį).
Techninio palaikymo (2 modulis) reikalavimai
- 1Užtikrinti nepertraukiamą Sistemos veikimą ir operatyvų reagavimą į sutrikimus.
- 2Fiksuotas mėnesinis mokestis apima: Incidentų valdymą (reagavimas į sutrikimus ir Sistemos veikimo atkūrimas), Programinių klaidų šalinimą (atsiradusių dėl Tiekėjo atliktų pakeitimų arba identifikuotų Perėmimo laikotarpiu), Prevencinę priežiūrą (ne rečiau kaip kartą per mėnesį atlikti Sistemos veiklos žurnalų peržiūrą, duomenų bazės indeksų fragmentacijos patikrą ir laikinų failų valymą), Bazinės programinės įrangos saugumo ir mažųjų atnaujinimų diegimą.
- 3Klaidos, objektyviai egzistavusios Sistemoje iki Sutarties pradžios ir nebuvusios identifikuotos Perėmimo metu, yra laikomos Vystymo darbais ir šalinamos taikant 3 Modulio įkainius, jeigu Šalys raštu nepatvirtina kitokios tokių klaidų klasifikacijos.
- 4Reagavimo laikas pradedamas skaičiuoti nuo kreipinio užregistravimo ITSM sistemoje momento.
- 5Pirminį Incidento prioritetą ir tipą nustato Užsakovas, vadovaudamasis Priede Nr. 1 apibrėžtais kriterijais. Tiekėjas turi teisę argumentuotai siūlyti keisti klasifikaciją, tačiau negali vienašališkai jos mažinti be išankstinio Užsakovo sutikimo.
- 6Reakcijos laikas laikomas įvykdytu tik tada, kai Tiekėjo specialistas Pagalbos tarnybos sistemoje pakeičia Incidento statusą į „Vykdoma“ ir įrašo pirminį komentarą.
- 7Sprendimo laikas stabdomas išimtinai tik šiais atvejais: laukiama Užsakovo atsakymo, gedimas yra išimtinai Užsakovo valdomos infrastruktūros arba išorinės sistemos pusėje, arba pritaikius Laikinąjį sprendimą, kuris atstato kritinį verslo procesą ir Užsakovas raštu tam pritaria.
- 8Draudžiama uždaryti Incidento bilietą ar stabdyti sprendimo laiką, jei realūs sprendimo veiksmai nebuvo atlikti ar Užsakovui nebuvo pateiktas išsamus atsakymas.
- 9Įvykus P1 lygio (Kritiniam) Incidentui, Tiekėjas privalo automatiškai inicijuoti Problemų valdymo procesą.
- 10Ne vėliau kaip per 5 darbo dienas po Kritinio Incidento išsprendimo, Tiekėjas privalo pateikti išsamią Priežasčių analizės (RCA) ataskaitą.
- 11Tiekėjas privalo pateikti Užsakovui detalias instrukcijas ir rekomendacijas, kuriuos failus, duomenų bazes ir konfigūracijas būtina saugoti bei kokiu periodiškumu rekomenduojama kurti kopijas.
- 12Tiekėjas atsako už visišką programinį Sistemos atkūrimą ir duomenų vientisumo patikrą po atkūrimo iš atsarginių kopijų tiek, kiek Incidento priežastis nėra susijusi su Užsakovo ar trečiųjų šalių atsakomybe.
- 13Šalys bendradarbiauja atlikdamos kasmetinį bandomąjį atkūrimą.
- 14Tiekėjas pateikia ataskaitą su visų Incidentų sąrašu ir SLA laikų faktinėmis reikšmėmis pasibaigus kalendoriniam mėnesiui.
Išplėstinių paslaugų (4 modulis) reikalavimai
- 1Paslaugos apmokamos pagal faktiškai skirtą (panaudotą) laiką taikant valandinį įkainį, fiksuojant jį 15 minučių tikslumu.
- 2Tiekėjas vykdo standartines užklausas, apimančias: Duomenų ištraukimą (gavimą), Konfigūraciją (Sistemos parametrų keitimą), Prieigos valdymą (vartotojų teisių suteikimą/panaikinimą, slaptažodžių atstatymą).
- 3Jei identiška ar iš esmės panaši užklausa pasikartoja daugiau nei 3 (tris) kartus per kalendorinį ketvirtį, Tiekėjas privalo kartu su mėnesine ataskaita pateikti Užsakovui rašytinį pasiūlymą dėl šio proceso automatizavimo (pagal 3 Modulio įkainius) arba savitarnos instrukcijos parengimo.
- 4Teikiamos aukštos kvalifikacijos specialistų (IT architektų, sistemų analitikų, saugumo ekspertų) konsultacijos šiose srityse: Mokymai, Analizė, Infrastruktūra.
- 5Konsultacijų metu pateiktos ekspertinės išvados ir rekomendacijos, turinčios esminės įtakos Sistemos architektūrai, našumui ar saugumui, privalo būti pateikiamos raštu.
- 6Vykdant konsultacijas per vaizdo konferencijų įrankius, privaloma naudoti tik Užsakovo patvirtintas komunikacijos platformas (pvz., „MS Teams“ ar lygiavertes Užsakovo valdomas aplinkas).
- 7Griežtai draudžiama įrašyti sesijas be visų dalyvių sutikimo ir išankstinio Užsakovo atsakingo asmens (pvz., Informacijos saugos vadovo) leidimo, ypač jei diskutuojama apie YSII architektūrą.
- 8Mažos apimties užduotys (iki 2 darbo valandų) gali būti vykdomos nedelsiant be išankstinio laiko sąmatos derinimo, tačiau bendra tokių darbų suma per kalendorinį mėnesį negali viršyti 10 (dešimties) valandų limito.
- 9Išimtis (vykdymas be išankstinio derinimo) taikoma tik „Skaitymo“ (angl. Read-only) tipo užduotims. Bet kokie Tiekėjo veiksmai, reikalaujantys Sistemos parametrų, konfigūracijų ar teisių keitimo, privalo būti iš anksto raštu patvirtinti Užsakovo, nepriklausomai nuo numatomos užduoties trukmės.
- 10Jei nenustatyta kitaip, standartinės paslaugų užklausos (iki 2 val.) įvykdomos per 1 darbo dieną nuo registravimo (arba sąmatos patvirtinimo).
- 11Tiekėjas privalo vesti detalią ir skaidrią laiko apskaitą.
- 12Jei konsultacijos metu buvo rastas sprendimas pasikartojančiai problemai arba atlikta sudėtinga, unikali Sistemos konfigūracija, Tiekėjas privalo parengti instrukciją ir įkelti ją į Užsakovo žinių bazę.
tendis.lt · Sukurta recodin.lt