Platforma Integrata de Monitorizare (PIM), o soluție software avansată, capabilă să gestioneze, coreleze și controleze multiple subsisteme și module de securitate publică și siguranță rutieră.
suma planificată 7,100,000.00 MDL
| Valoare | CPV | Titlu achiziției | Cantitate | Livrare |
|---|---|---|---|---|
| 7,100,000.00 MDL | 48200000-0 | Platforma Integrată de Monitorizare | 1 Bucata |
25.07.2025 - 30.12.2025 str.Vasile Alecsandri nr.42 |
cerința 178 – „Platforma trebuie să asigure actualizarea automată și manuală a listei de interes, cu posibilitatea de a adăuga sau elimina vehicule pe baza informațiilor furnizate de autorități” – vă rugăm să clarificați:
În ce format și prin ce mijloace vor fi furnizate listele de interes de către autoritățile competente?
Conform cerinței 178 din caietul de sarcini, platforma trebuie să asigure posibilitatea de actualizare a listei de interes atât manual, cât și automat, în baza informațiilor primite de la autoritățile competente.
Formatul și mijloacele de furnizare a listelor de interes vor fi stabilite în etapa de implementare, în funcție de capacitățile tehnice ale autorităților implicate. Totuși, platforma trebuie să fie pregătită să primească și să proceseze listele de interes în formate deschise și standardizate, cum ar fi:
• CSV, XML, JSON, în cazul integrării automate;
• Formulare dedicate în interfața de administrare, pentru adăugarea manuală;
• Prin API securizat, în cazul integrării cu baze de date sau sisteme externe (de exemplu, cele gestionate de autoritățile de aplicare a legii).
Este responsabilitatea ofertantului să demonstreze că platforma ofertată poate gestiona ambele metode (manual și automat) și să descrie mecanismul de integrare pentru fiecare format menționat. Astfel, soluția trebuie să fie flexibilă și adaptabilă la sursele de date utilizate în cadrul autorităților beneficiare.
În legătură cu cerința 180 – vă rugăm să clarificați:
Ce anume se are în vedere prin „vizualizarea traseului”?
Este suficientă afișarea cronologică a locațiilor înregistrate?
Cerința 180 prevede ca platforma să permită vizualizarea traseului unui vehicul înregistrat în sistem pe baza datelor colectate de camerele ANPR sau alte surse relevante.
Prin „vizualizarea traseului” se înțelege reprezentarea grafică și cronologică a succesiunii locațiilor în care vehiculul a fost detectat, astfel încât utilizatorul să poată urmări parcursul acestuia într-un mod intuitiv și operativ.
Afișarea cronologică a locațiilor (de exemplu, într-o listă cu timp, dată, locație, imagine) este necesară, dar nu este suficientă. Se solicită în mod expres afișarea traseului și pe hartă, prin reprezentarea punctelor de detecție, în ordinea apariției, cu posibilitatea de a accesa cel puțin detalii precum:
• Imaginea capturată la fiecare punct,
• Data, ora, minuta, secunda trecerii,
• Direcția de deplasare,
• Alte atribute colectate (număr de înmatriculare, culoare, model etc.).
Referitor la cerința 182 – vă rugăm să specificați:
1. Care este sistemul de gestionare a contravențiilor utilizat în prezent de către autoritatea contractantă?
2. Ce tip de interfață sau protocoale de integrare sunt disponibile
Integrarea cu acest sistem se va realiza prin intermediul platformei de interoperabilitate guvernamentală MConnect, care permite schimbul standardizat de date între sisteme informaționale ale autorităților publice.
Protocoalele de integrare disponibile:
REST API, cu autentificare și autorizare securizată;
Web services (SOAP), în funcție de cerințele părții terțe;
Format de date structurat: JSON sau XML;
Documentația tehnică aferentă va fi pusă la dispoziția ofertantului selectat, în cadrul etapei de implementare.
Referitor la cerința 189 – vă rugăm să ne oferiți următoarele detalii:
1. Care sunt sistemele concrete de gestionare a incidentelor cu care se preconizează sincronizarea platformei?
2. Ce metodă sau protocoale de sincronizare sunt utilizate sau se doresc
Cerința se refera la subsistemele platformei care trebuie sa fie parte integrantă a ofertei. Pentru clarificarea mai multor cerințe funcționale aferentei clarificării dvs, a se analiza subsecțiunea 5.5.
Referitor la cerința nr. 205 privind reacția automată a camerelor PTZ în funcție de evenimente detectate de alte sisteme, vă rugăm să specificați:
1. Care sunt tipurile de evenimente acceptate sau prevăzute ca declanșatori pentru acțiunea PTZ?
2. Cum trebuie să reacționeze camera – este vorba despre trimiterea la un preset, activarea urmăririi automate (auto-tracking), sau alt comportament?
Cerința se referă la capacitatea și funcționalitatea platformei de configurare de scenarii automate în baza evenimentelor de interes care servesc ca declanșatori pentru acțiuni de răspuns, sau măsuri de reacție. Platforma trebuie sa permită configurarea evenimentelor fără a se limita la un set predefinit de declanșatori, ci să asigure flexibilitatea de definire a declanșatorilor în funcție de necesitățile operaționale. Din această perspectivă ”tipurile de evenimente acceptate sau prevăzute” presupune o abordare limitată. Ca exemplu totuși, dar fără a fi limitată putem menționa: detectarea unui vehicul cu număr de înmatriculare din lista de interes, traversarea unei linii virtuale, identificarea unei persoane dintr-o listă de supraveghere, etc.
Reacția camerei trebuie să poată fi configurată în funcție de scenariu și poate include, printre altele: trimiterea camerei PTZ într-o poziție presetată, activarea funcției de urmărire automată, inițierea înregistrării video sau afișarea imaginii camerei în interfața operatorului - în funcție de dispozitiv și operațiunile suportate.
Referitor la analiza activității pietonale solicitată în cerința nr. 211, vă rugăm să specificați:
1. Ce anume se înțelege prin „analiza activității pietonale”?
2. Ce tipuri de comportamente, acțiuni sau scenarii trebuie să fie detectate?
3. Care este scopul principal urmărit prin aceasta functionalitate?
Cerința ține de capacitățile platformei de analiză video avansată. A se vedea capitolul 5.3 – Analiza video avansată din caietul de sarcini.
Vă rugăm să specificați ce tipuri de mișcări anormale sunt avute în vedere de autoritatea contractantă în cadrul cerinței privind detecția automată a comportamentelor suspecte.
Cerința urmărește ca platforma să fie capabilă să detecteze automat mișcări neobișnuite (anomalii dinamice) ale persoanelor sau obiectelor monitorizate într-un spațiu public sau supravegheat, care pot indica un potențial risc sau incident.
De exemplu: deplasare în sens interzis; deplasare haotică; traiectorii neobișnuite; fugă bruscă; mișcare lentă prelungită; opriri nejustificate; aglomerație rutieră într-un interval orar considerat liber; etc.
Raspuns pentru cerința nr. 267:
Prin „reconstrucția secvențelor video” se înțelege capacitatea platformei de a permite revizuirea și reconstituirea detaliată a unui incident, prin accesarea automată sau asistată a înregistrărilor relevante, corelarea evenimentelor, afișarea cronologică sincronizată din mai multe camere, suprapunerea metadatelor și evidențierea comportamentelor detectate. Platforma trebuie să asigure redarea contextualizată a incidentului, incluzând momentele premergătoare și ulterioare, pentru a permite înțelegerea completă a desfășurării evenimentului.
Platformei trebuie să permită revizuirea și reconstituirea detaliată a unui incident, prin spre exemplu:
• accesarea rapidă a înregistrărilor video asociate unui eveniment sau comportament detectat automat;
• redarea sincronizată a secvențelor din mai multe camere implicate;
• generarea automată de clipuri video care includ momentele de dinainte și după evenimentul detectat;
• afișarea de informații suplimentare asociate (metadate), precum casete de delimitare ale obiectelor implicate și descrieri automatizate ale comportamentului;
• posibilitatea de urmărire a traiectoriei unei persoane sau a unui vehicul între camere diferite;
• marcare temporală (bookmark) și export al secvenței video împreună cu datele asociate, pentru analiză, raportare sau arhivare.
Vă rugăm să descrieți ce anume se înțelege, în viziunea autorității contractante, prin „reconstrucția secvențelor video”.
Cerința urmărește ca platforma să fie capabilă să detecteze automat mișcări neobișnuite (anomalii dinamice) ale persoanelor sau obiectelor monitorizate într-un spațiu public sau supravegheat, care pot indica un potențial risc sau incident.
De exemplu: deplasare în sens interzis; deplasare haotică; traiectorii neobișnuite; fugă bruscă; mișcare lentă prelungită; opriri nejustificate; aglomerație rutieră într-un interval orar considerat liber; etc.
Vă rugăm să detaliați ce se înțelege prin „funcționalități de înregistrare a vehiculelor identificate în componenta de analiză a traficului rutier”. Ce tipuri de date si parametric se așteaptă să fie înregistrate pentru fiecare vehicul?
Prin „funcționalități de înregistrare a vehiculelor identificate” se înțelege capacitatea platformei de a stoca automat, într-o structură de date organizată, toate informațiile relevante asociate fiecărui vehicul detectat prin camerele ANPR și alte sisteme de supraveghere video și senzori, în scopul analizei și investigației ulterioare.
Numărul de înmatriculare (recunoscut automat prin ANPR);
Tipul vehiculului (autoturism, camion, motocicletă etc.);
Marca și modelul (dacă este posibil);
Culoarea predominantă;
Caracteristici particulare (ex. absența plăcuței, remorcă atașată etc.).
Data și ora exactă a detectării;
Locația (camera/senzorul/segmentul de drum unde a fost detectat vehiculul);
Direcția de deplasare;
Viteza estimată (dacă sistemul are capacitatea de detecție a vitezei).
Aparținerea vehiculului unei liste de interes (dacă e cazul);
Asocierea cu un eveniment sau incident detectat;
Gradul de risc atribuit (în baza unor reguli predefinite).
Link către înregistrarea video corespunzătoare;
Capturi foto (snapshots) din momentul detecției;
Harta cu traseul parcurs (dacă este detectabil)
Integrare cu alte funcționalități. Informațiile înregistrate trebuie să poată fi:
Căutate după mai mulți parametri;
Corelate cu evenimente din sistemul de gestionare a incidentelor;
Exportate în rapoarte și analize vizuale (dashboard, hărți de trafic etc.).
Platforma trebuie să înregistreze, pentru fiecare vehicul identificat, un set complet de date vizuale, spațiale, temporale și operaționale, care să permită analiza comportamentală, investigarea incidentelor și raportarea statistică, în deplină conformitate cu cerințele expuse în caietul de sarcini.
Referitor la cerința nr. 296, privind automatizarea răspunsului pentru situații de rutină, vă rugăm să specificați ce tipuri de situații sunt considerate de către beneficiar ca fiind „de rutină” și care anume se preconizează a fi gestionate automat?
Prin „situații de rutină” se înțeleg acele evenimente sau scenarii recurente, cu risc scăzut, care pot fi gestionate în mod automatizat, fără a necesita intervenția imediată a unui operator uman, dar care trebuie totuși înregistrate, documentate și, după caz, notificate.
Exemple de situații considerate „de rutină” și care pot fi automatizate:
Depășirea vitezei legale într-un prag de toleranță prestabilit;
Detectarea vehiculelor parcate neregulamentar
Identificarea vehiculelor aflate în lista de interes
Fluxuri de trafic congestionat repetitiv, în intervale orare predictibile
Scopul automatizării: reducerea încărcării operatorilor umani cu sarcini repetitive și creșterea eficienței sistemului, asigurând totodată trasabilitate completă și intervenție proactivă atunci când este cazul.
Referitor la cerința nr. 300, privind necesitatea ca platforma să permită configurarea și gestionarea fluxurilor de lucru personalizate printr-o interfață de tip drag-and-drop, considerăm că această cerință este una foarte specifică și restrictivă.
Pentru a asigura respectarea principiului tratamentului egal și a neasigurării unui avantaj competitiv indirect unui anumit brand (ex. Genetec), vă rugăm să reconsiderați această cerință și să o includeți ca opțională, nu obligatorie.
În cazul în care considerați oportună menținerea ei ca obligatorie, vă rugăm să indicați cel puțin două-trei soluții distincte disponibile pe piață care oferă demonstrabil această funcționalitate în forma menționată, pentru a demonstra caracterul competitiv și deschis al specificației tehnice.
Cerința privind configurarea și gestionarea fluxurilor de lucru personalizate printr-o interfață grafică de tip drag-and-drop sau similar nu reprezintă o referință la o tehnologie proprietară sau la un producător anume. Este vorba despre o funcționalitate de ordin general, regăsită la nivel internațional în multiple soluții comerciale, care permite modelarea vizuală și intuitivă a scenariilor operaționale complexe, fără intervenție tehnică avansată.
Această cerință este justificată de nevoia autorității contractante de a beneficia de o platformă configurabilă și adaptabilă în timp real la evenimente și incidente, într-un mod accesibil personalului operativ (non-tehnic). Prin urmare, ea reflectă cerințele legale prevăzute la art. 37 alin. (1) din Legea nr. 131/2015 privind achizițiile publice, care permite stabilirea de specificații tehnice clare în conformitate cu obiectivele și necesitățile autorității. Astfel, cerinta nu limitează concurența, ci definește un nivel de funcționalitate dorit, care poate fi atins prin diverse abordări tehnologice conforme.
În concluzie, cerința se menține ca obligatorie, acceptindu-se tehnologii similare drag-and-drop, întrucât corespunde nevoilor autorității contractante.
Referitor la cerința nr. 275, privind determinarea vitezei de deplasare a vehiculelor în timp real cu o marjă de eroare de cel mult 10%, vă rugăm să specificați dacă se are în vedere utilizarea de camere video (cu funcționalitate radar integrată si certificare metrologică) sau radare specializate?
Menționăm că, în lipsa unor dispozitive hardware specializate, estimarea software a vitezei poate avea o marjă de eroare flotanta si instabila și ar putea servi drept proba juridical de constatare a unei incalcari.
Pentru a asigura un tratament egal al ofertanților, vă rugăm să precizați dacă această cerință poate fi retrasa, întrucât sunt lezate drepturile unor tratamente echitabile si participare ne-restrictiva.
Cerința nr. 275 vizează determinarea vitezei vehiculelor în scopuri de analiză și investigare, nu pentru constatarea juridică a contravențiilor. În acest sens, nu se solicită obligativitatea certificării metrologice.
Se solicită asigurarea unui mecanism tehnic care nu implică utilizarea unor senzori fizici de măsurare și care permite o estimare orientativă a vitezei cu marja de eroare menționată (≤10%), în scopuri analitice.
Această abordare nu restricționează participarea ofertanților și permite adaptarea la arhitecturi hibride sau modulare.
Referitor la cerința nr. 271, privind suportul pentru formatele de compresie video H.264, H.265, MPEG-4, MPEG-2 și MJPEG, vă rugăm să reevaluați necesitatea includerii formatului MPEG-2, întrucât acest standard este considerat tehnologic depășit și ineficient din punct de vedere al compresiei și stocării.
Adnotam faptul, că începând cu data de 3 ianuarie 2024, toate brevetele aferente MPEG-2 au expirat la nivel mondial, ceea ce face ca standardul să nu mai fie susținut activ de majoritatea producătorilor de soluții moderne de supraveghere video.
În acest context, pentru a evita impunerea unor cerințe anacronice care pot restrânge inutil participarea unor soluții moderne, vă rugăm să reconsiderați eliminarea MPEG-2 din lista de formate obligatorii.
Cerința privind suportul pentru formatele H.264, H.265, MPEG-4, MPEG-2 și MJPEG a fost formulată pentru a asigura compatibilitatea retroactivă cu dispozitive video existente sau cu înregistrări istorice provenite din infrastructura deja implementată în anumite locații.
Totodată, autoritatea contractantă confirmă că utilizarea activă a formatului MPEG-2 nu este obligatorie pentru funcționarea curentă, ci doar pentru scopuri de interoperabilitate sau import de conținut anterior.
Referitor la cerința nr. 234, privind integrarea cu Registrul de Stat al Populației (RSP) și Registrul Informațiilor Criminalistice și Criminologice (R1CC), vă rugăm să clarificați dacă platformei VMS i se solicită doar capabilitatea de a primi și utiliza informațiile transmise printr-un API furnizat de autoritatea competentă.
Menționăm că aceste sisteme sunt gestionate de instituții publice și accesul la ele este strict reglementat. Astfel, orice sincronizare automată, inclusiv extragerea imaginilor persoanelor căutate, presupune existența unui mecanism de interoperabilitate pus la dispoziție de către autorități, și nu poate fi responsabilitatea directă a VMS-ului.
În acest sens, vă rugăm să specificați:
• dacă există un API documentat pentru accesul la aceste date pus la dispozitie dupa incheierea unui contract;
• dacă sincronizarea periodică se va face printr-un serviciu extern care livrează datele către VMS;
• și dacă această cerință poate fi reformulată astfel încât platforma să suporte integrarea, în cazul în care autoritatea furnizează accesul și formatele de date necesare, dar nu invers.
Cerința nr. 234 vizează funcționalitățile platformei, nu a modului VMS, care este parte componenta a acesteia, prin urmare platforma trebuie sa fie capabila si sa implementeze se referă la capacitatea tehnică a platformei de a permite integrarea cu registrele menționate, nu la responsabilitatea directă a ofertantului de a implementa integrarea în lipsa unui mecanism oficial de interoperabilitate. Aspectele de reglementare țin exclusiv de responsabilitatea Autorității Contractante. Ofertantul trebuie sa asigure ca oferta este pe deplin conforma cerințelor si corespunde nevoilor si așteptărilor autorității contractante.
Prin urmare, cerința se menține, dar interpretarea sa trebuie înțeleasă ca neimpunând obligația realizării efective a integrării în lipsa accesului legal, ci doar disponibilitatea tehnică a platformei pentru a asigura interoperabilitatea in modul definit in cerințele tehnice
Referitor la cerința nr. 133, conform căreia platforma trebuie să suporte dezvoltarea și implementarea de algoritmi personalizați pentru analiza datelor, vă rugăm să specificați în mod clar:
1. Ce tip de algoritmi se au în vedere?
2. Ce nivel de acces este vizat?
3. Vă rugăm să furnizați exemple concrete de cazuri de utilizare pe care autoritatea le are în vedere pentru a putea evalua relevanța și fezabilitatea tehnică a cerinței în raport cu funcționalitatea unui VMS.
Cerința nr. 133 vizează funcționalitățile platformei, nu a modului VMS, care este parte componenta a acesteia, prin urmare platforma trebuie sa fie capabila si sa implementeze o arhitectura deschisa care să permită dezvoltarea și integrarea de algoritmi personalizați(inclusiv alte subsisteme) pentru analiza datelor operaționale sau video în cadrul platformei, fără a limita utilizarea la funcționalitățile predefinite ale producătorului.
Clarificări:
a. Prin „algoritmi personalizați” se înțelege posibilitatea de a dezvolta sau integra module proprii (ex. scripturi, modele AI/ML, reguli analitice) pentru prelucrarea datelor, recunoașterea de tipare comportamentale, clasificarea obiectelor sau alte analize relevante pentru securitate.
b. Nivelul de acces vizat presupune acces la API-uri, SDK sau interfețe de extensie (plug-in framework) care permit adăugarea acestor componente, fără a necesita modificări ale codului sursă al platformei.
Exemple de cazuri de utilizare vizate:
• dezvoltarea unui algoritm care să detecteze comportamente anormale într-un anumit spațiu (ex: traversare în afara trecerii de pietoni în zone aglomerate);
• implementarea unui filtru AI pentru recunoașterea anumitor obiecte (ex: arme albe, saci voluminoși abandonați);
• aplicarea unor algoritmi specifici pentru detectarea anumitor vehicule (ex: transport agabaritic, vehicule școlare, etc.).
Cerința nu impune livrarea unor algoritmi concreți, ci doar deschiderea arhitecturii platformei pentru astfel de integrări viitoare, în funcție de necesitățile beneficiarului. Această flexibilitate este esențială pentru adaptarea sistemului în timp și nu presupune favorizarea unui anumit furnizor.
Referitor la cerința nr. 125, vă rugăm să specificați dacă prin „detectarea și prevenirea tentativelor de acces neautorizat” se face referire la:
• a) accesul fizic în perimetre securizate (prin integrare cu sisteme de control acces),
• b) accesul neautorizat la platforma software (securitate IT), sau
• c) ambele.
Totodată, vă rugăm să precizați dacă se acceptă implementarea funcționalității de prevenție și blocare automată prin integrare cu sisteme externe (control acces, firewall etc.), întrucât platformele VMS nu blochează direct accesul, ci pot emite comenzi automate către subsisteme care gestionează fizic sau logic accesul.
Cerința nr. 125 se referă atât la prevenirea accesului logic la platforma software, deci vizează Acces logic/software – detectarea și prevenirea tentativelor de acces neautorizat în platforma informatică (ex: autentificări eșuate repetate, acces din locații nesigure, tentative de escaladare a privilegiilor etc.), conform cerințelor de securitate IT și audit menționate în alte puncte ale caietului de sarcini
Vă rugăm să specificați dacă cerința privind utilizarea de chei de criptare generate aleatoriu, cu rotație periodică, se referă la:
• criptarea transmisiilor video între camere și platformă (ex: RTSP over TLS),
• criptarea metadatelor și a fișierelor în timpul stocării,
• sau la criptarea comunicațiilor de rețea între componente (servere, clienți).
Cerința nr. 115, referitoare la utilizarea de chei de criptare generate aleatoriu, cu rotație periodică, se aplică în mod extins tuturor nivelurilor de comunicație și stocare în cadrul platformei, astfel:
a. Criptarea transmisiilor video între camere și platformă – Da, acolo unde este posibil (în funcție de capabilitățile camerelor), transmisia video trebuie să fie protejată (ex. prin RTSP over TLS sau protocoale similare securizate), pentru a preveni interceptarea datelor video în rețea.
b. Criptarea metadatelor și a fișierelor în timpul stocării – Da, cerința include și criptarea la nivel de storage (atât pentru datele video, cât și pentru metadate, fișiere jurnal, baze de date interne etc.), utilizând algoritmi și chei moderne de criptare, gestionate conform unei politici interne de rotație.
c. Criptarea comunicațiilor de rețea între componente (servere, clienți) – Da, platforma trebuie să asigure canale securizate între componentele sale interne (servere, stații de lucru, interfețe de administrare), prin protocoale precum TLS, VPN, SSH sau echivalente.
Despre rotația cheilor: Cerința de rotație periodică a cheilor implică:
generare aleatorie a noilor chei criptografice,
actualizarea acestora fără afectarea serviciilor critice,
gestionare centralizată și auditabilă a cheilor (ex. printr-un modul de tip KMS – Key Management System).
Cerința are un caracter general de securizare a întregului ecosistem, iar implementarea poate fi realizată atât nativ în platformă, cât și prin integrare cu soluții specializate de criptare și gestionare a cheilor.
Referitor la managementul centralizat al cheilor de criptare, vă rugăm să precizați dacă este acceptabil ca această funcționalitate să fie realizată prin integrarea platformei VMS cu un sistem de tip KMS (Key Management System) furnizat de beneficiar sau terți? Consideram ca este o cerinta care limiteaza particparea echitabila la concurs prin impunerea conditiilor irealizabile de catre alti furnizori, or rugam enumerarea solutiilor care pot indeplini cerinta data.
Cerința nr. 116 vizează funcționalitățile platformei, nu a modului VMS, care este parte componenta a acesteia, prin urmare platforma trebuie sa fie capabila sa gestioneze cheile intr-un mod centralizat, sau prin integrarea cu solutii specializate care asiugra acest lucru.
Clarificare: Scopul cerinței este asigurarea unui nivel ridicat de securitate în gestionarea cheilor criptografice, astfel încât procesul de criptare/decriptare să fie controlat centralizat și în siguranță. Această cerință nu impune utilizarea unei soluții închise sau proprietare, ci permite soluții compatibile, interoperabile, deschise.
Vă rugăm să specificați ce tipuri de activități sunt considerate „tentative de acces neautorizat sau abuz” în contextul activității administratorilor și utilizatorilor privilegiați.
Totodată, vă rugăm să confirmați dacă este acceptabilă implementarea auditului prin loguri detaliate (audit trail)
În contextul cerinței nr. 104, prin „tentative de acces neautorizat sau abuz” se înțeleg orice acțiuni realizate de administratori sau utilizatori privilegiați care încalcă politicile de acces, securitate sau confidențialitate stabilite de autoritatea contractantă, inclusiv, dar fără a se limita la:
Exemple de activități considerate tentativă de acces neautorizat sau abuz:
a. accesarea nejustificată a unor date sau fluxuri video clasificate sau cu acces restricționat;
b. modificarea neautorizată a configurațiilor critice ale platformei;
c. ștergerea intenționată sau accidentală a înregistrărilor fără autorizare;
d. escaladarea neautorizată a propriilor drepturi de acces;
e. vizualizarea sau exportarea datelor în afara cazurilor de utilizare aprobate;â
f. încercări repetate de conectare cu credențiale greșite (posibil atac de tip brute force).
Măsuri tehnice acceptate: Da, este acceptabilă și recomandată implementarea auditului prin loguri detaliate (audit trail), care să includă:
a. identificarea utilizatorului (ID, IP, sesiune);
b. acțiunea efectuată (login, acces fișiere, modificări, export, ștergere);
c. timestamp complet (dată și oră exactă);
d. rezultatul acțiunii (reuşită/eșec);
e. alte atribute (resurse accesate, nivel de autorizare etc.).
Alte cerințe implicite. Platforma trebuie să permită:
monitorizarea și detectarea în timp real a acțiunilor suspecte;
generarea de alerte automate în cazul activităților deviante;
posibilitatea exportului și analizării logurilor pentru audit extern sau intern;
protejarea și arhivarea logurilor pentru o perioadă minimă conform politicii de retenție a autorității contractante.
Cerința permite implementarea funcționalității prin mecanisme standardizate de audit trail, ceea ce corespunde cu bunele practici internaționale în domeniul securității IT și al sistemelor critice.
Vă rugăm să specificați:
• Care tip/model anume de sisteme de semaforizare sau control acces sunt avute în vedere pentru integrare cu platforma mobilă?
• Ce echipamente specifice sau protocoale sunt utilizate sau așteptate (ex: Modbus, OPC, ONVIF, alte API-uri)?
• Ce se înțelege prin „suprascrierea programelor de blocare” – este vorba despre o funcție disponibilă în sistemele integrate (de exemplu, control acces fizic) sau despre o comandă directă din platforma mobilă către echipamentele respective?
În legătură cu cerința nr. 98, clarificările sunt următoarele:
Tip/model de sisteme de semaforizare sau control acces avute în vedere pentru integrare. Nu se impune un anumit producător sau model anume. Platforma mobilă trebuie să fie permită controlul inclusiv asistemelor de semaforizare și control acces integrate
Nu este impusă o restricție de echipamente specifice sau protocoale.
„Suprascrierea programelor de blocare” – interpretare: Această formulare face referire la posibilitatea platformei de a transmite comenzi către sistemele de control acces sau semaforizare integrate pentru a modifica comportamentul acestora, în situații de interes (incident, urgență, escortă, intervenție etc.).