Selectaţi tipul procedurii
1
Perioada de actualizare
de la
06.10.2026 15:27
până la 18.10.2026 12:21
până la 18.10.2026 12:21
2
Propunerea ofertelor
de la
18.10.2026 12:21
până la 24.10.2026 12:21
până la 24.10.2026 12:21
3
Licitaţie
nu va fi folosită
4
Evaluare
5
Contract
Statut
Evaluare
Valoarea estimată fără TVA
600 000 MDL
Perioada clarificărilor:
6 oct 2026, 15:27 - 18 oct 2026, 12:21
Perioada de depunere a ofertelor:
18 oct 2026, 12:21 - 24 oct 2026, 12:21
Suport Tehnic pentru furnizori:
(+373) 79999801
Aceasta procedura se va desfășura fară licitație electronică. Oferta Dvs. este finală și trebuie să conțină toată lista de documente cerută de documentația de atribuire.
Imposibil de abonat
în perioada Evaluare
Servicii Achiziționare licențe pentru solutii PAM
Informaţia despre solicitant
Codul fiscal/IDNO
Adresa
2062, MOLDOVA, mun.Chişinău, locality, Dacia bd. nr.58/C
Web site
---
Persoana de contact
Datele achizitiei
Data publicării
6 oct 2026, 15:19
Data ultimilor modificări
9 oct 2026, 15:48
Achizitii.md ID
21687328
MTender ID
CPV
72200000-7 - Servicii de programare şi de consultanţă software
Tipul procedurii
Licitație deschisă
Criteriu de atribuire
Preţul cel mai scăzut
Surse de finanțare
Lista loturilor
Documentele procedurii de achiziție
Data:
9 oct 2026, 15:48
Subiectul întrebării:
Solicitare de clarificare tehnică -numar resurse ce se dorestea a fi monitorizat?
Întrebare:
Stimați domni,
În vederea elaborării unei oferte tehnice optimizate și pentru dimensionarea corectă a arhitecturii hardware/virtuale (inclusiv a nodurilor de High Availability / Redundanță și Gateway-urilor de acces), vă rugăm respectuos să ne furnizați câteva precizări de ordin tehnic privind mediul dumneavoastră informatic.
Pentru a ne asigura că soluția propusă va asigura un nivel optim de performanță și stocare a înregistrărilor de sesiune, vă rugăm să ne indicați o estimare orientativă a numărului de resurse/echipamente țintă ce urmează a fi integrate în platforma PAM, defalcate preferențial pe următoarele categorii:
Servere: Număr estimat de servere Windows și Linux/Unix.
Echipamente de rețea și securitate: Număr estimat de routere, switch-uri, firewall-uri, SBC-uri.
Baze de date și Aplicații: Număr estimat de instanțe/baze de date enterprise (MS SQL, PostgreSQL, etc.) sau portaluri administrative.
Sesiuni concomitente: Numărul maxim estimat de sesiuni administrative paralele/simultane (RDP/SSH) desfășurate la un moment dat.
Răspuns (12 oct 2026, 18:08):
Stimați operatori economici,
Informațiile privind infrastructura beneficiarului și numărul sesiunilor concomitente au caracter sensibil. Ele vor fi comunicate ofertantului desemnat câștigător după semnarea contractului, în baza unui acord de confidențialitate, în cadrul etapei de proiectare și implementare.
Aceste informații nu influențează modelul de licențiere. Conform caietului de sarcini, soluția trebuie licențiată perpetuu pentru 10 administratori/tehnicieni ai platformei PAM. Licențierea trebuie să permită creșterea numărului de utilizatori non-administrativi, de resurse și de conturi administrate fără licențe suplimentare calculate individual per utilizator sau per resursă. Cerința se interpretează în sensul că licențierea ofertată nu va impune limitări privind numărul de sesiuni privilegiate concomitente și nici licențe suplimentare pentru gateway-uri sau pentru nodurile de redundanță ori de stocare a înregistrărilor necesare scalării soluției.
Cerințele caietului de sarcini rămân neschimbate.
Data:
13 oct 2026, 11:58
Subiectul întrebării:
Răspuns (12 oct 2026, 18:08):
Întrebare:
Vă mulțumim pentru răspunsul oferit anterior și pentru reconfirmarea modelului de licențiat perpetuu pentru 10 administratori, fără limitări pe numărul de resurse.
Revenim cu o solicitare de nuanțare a cerinței, strict din perspective pur tehnice și de dimensionare a arhitecturii de High Availability (HA - 2 noduri) și stocare a înregistrărilor, impusă de producătorii de soluții de tip PAM (Privileged Access Management).
Pentru a putea oferi o soluție stabilă, performantă și adaptată cerințelor de disponibilitate din Caietul de Sarcini, vă rugăm să ne sprijiniți cu un ordin de mărime sau un prag orientativ minim (chiar și sub formă de intervale agregate, fără detalii topologice sensibile):
Ordinul de mărime al resurselor vizate: Se încadrează parcul de echipamente vizat pentru onboarding (servere Windows/Linux, dispozitive de rețea) în intervalul de zeci de ținte (ex. sub 50), sute de ținte (ex. 100 - 300) sau peste 500 de ținte?
Sesiuni concomitente: Pentru dimensionarea corectă a clusterului de gateway-uri și a stocării video, este estimat un vârf de utilizare de sub 10, între 10 și 30, sau peste 30 de sesiuni simultane (RDP/SSH)?
Fără un ordin de mărime tehnic de la beneficiar, producătorul soluției software nu poate valida arhitectura fizică/virtuală minimă (vCPU, RAM, spațiu de stocare pentru Session Recording pe 12 luni), existând riscul ca sistemul livrat să nu corespundă cerințelor de performanță la punerea în producție.
Vă mulțumim anticipat pentru deschidere și sprijinul acordat în vederea depunerii unei oferte tehnice riguroase.
Răspuns (15 oct 2026, 09:09):
Stimate operator economic,
Caietul de sarcini nu stabilește un număr determinat de noduri HA și nici o perioadă de păstrare de 12 luni pentru înregistrările sesiunilor. Ofertantul va propune arhitectura și cerințele de infrastructură corespunzătoare soluției ofertate, cu respectarea cerințelor de scalabilitate, disponibilitate, backup și restaurare prevăzute în documentație.
Informațiile privind numărul resurselor, sesiunile concomitente și infrastructura beneficiarului au caracter sensibil și vor fi comunicate ofertantului desemnat câștigător în etapa de analiză și implementare. Arhitectura și configurația propuse trebuie să permită utilizarea și extinderea ulterioară a platformei fără a afecta modelul de licențiere solicitat sau drepturile de utilizare a funcționalităților software achiziționate.
Aceste informații nu influențează modelul de licențiere. Rămân aplicabile cerințele privind licențierea perpetuă pentru 10 administratori/tehnicieni și posibilitatea creșterii numărului de utilizatori non-administrativi, resurse și conturi administrate fără licențe suplimentare calculate individual per utilizator, resursă sau cont.
Cerințele caietului de sarcini rămân neschimbate.
Mentenanța PAM
Data:
15 oct 2026, 14:57
Subiectul întrebării:
Platforma trebuie să fie implementată on-premises și să acopere administrarea conturilor/secrets, controlul accesului, rotația credențialelor, sesiunile, elevarea temporară și integrarea cu identitatea, ITSM și SIEM.
Întrebare:
Se acceptă o soluție care oferă integrare prin REST API cu sistemele ITSM și acces Just-in-Time (JIT) la conturile privilegiate, cu sesiuni limitate în timp, mecanisme de aprobare și audit complet?
Având în vedere că specificarea unor mecanisme tehnice foarte restrictive poate favoriza un anumit producător și poate limita participarea altor integratori de pe piața locală, vă rugăm să confirmați că vor fi acceptate și soluțiile care asigură funcționalitățile solicitate prin mecanisme echivalente.
Răspuns (16 oct 2026, 11:27):
Da. Sunt acceptate mecanismele echivalente care asigură acces privilegiat limitat în timp, justificare, aprobare, revocare automată și audit complet. Integrarea ITSM poate fi realizată nativ sau prin API ori conector documentat, cu respectarea tuturor rezultatelor solicitate în caietul de sarcini.
Accesul limitat în timp la un cont privilegiat permanent, prin injectarea credențialelor, acoperă cerințele privind accesul privilegiat și managementul sesiunilor, dar nu substituie cerința distinctă privind elevarea temporară a privilegiilor. Pentru această cerință, privilegiile trebuie acordate temporar identității utilizatorului sau unui cont creat ori activat temporar și retrase automat la check-in, la expirare sau la încheierea sesiunii.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 14:58
Subiectul întrebării:
Integrare cu infrastructura de identitate, sistemele ITSM și SIEM, precum și cu instrumentele de automatizare.
Întrebare:
Este corect să înțelegem că cerința poate fi îndeplinită și prin utilizarea API-urilor standard și a protocoalelor de integrare? De asemenea, se acceptă o soluție care oferă REST API v2 pentru integrarea cu sistemele ITSM și instrumentele de automatizare, precum și transmiterea evenimentelor către SIEM prin syslog?
Răspuns (16 oct 2026, 11:30):
Da. Integrarea cu sistemele ITSM și instrumentele de automatizare poate fi realizată prin API-uri standard documentate. Transmiterea evenimentelor către SIEM poate fi realizată prin integrare nativă sau prin Syslog TCP, UDP ori TLS. Ofertantul trebuie să demonstreze inclusiv selectarea categoriilor de evenimente transmise și păstrarea auditului local.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 14:58
Subiectul întrebării:
Controlul aplicațiilor/comenzilor privilegiate pe sistemele suportate.
Întrebare:
Este corect să înțelegem că cerința privind controlul aplicațiilor și comenzilor privilegiate poate fi considerată îndeplinită prin utilizarea mecanismelor de detectare a comenzilor pe baza expresiilor regulate (regex), a listelor de comenzi permise pentru Linux prin intermediul pluginului sudo și a restricționării accesului la aplicațiile aprobate prin RDP RemoteApp, cu posibilitatea aplicării unor acțiuni de control, precum suspendarea sau terminarea sesiunii ori blocarea utilizatorului, în cazul detectării comenzilor nepermise?
Răspuns (16 oct 2026, 11:32):
Mecanismul descris poate fi acceptat dacă permite definirea și aplicarea listelor sau grupurilor de comenzi permise și/sau interzise, restricționarea aplicațiilor autorizate, aplicarea politicilor pe conturi, resurse sau grupuri de resurse, auditarea comenzilor și modificărilor de politici și, unde este cazul, suspendarea, blocarea sau terminarea sesiunii.
Simpla detectare sau raportare a unei comenzi, fără posibilitatea aplicării acțiunilor de control solicitate, nu este suficientă.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 14:58
Subiectul întrebării:
API și mecanisme pentru eliminarea secretelor hard-coded din aplicații și scripturi.
Întrebare:
Este corect să înțelegem că cerința privind eliminarea secretelor hard-coded din aplicații și scripturi poate fi considerată îndeplinită prin utilizarea unui API REST securizat, care permite solicitarea și recuperarea secretelor la momentul execuției (runtime), pe baza unei chei API, cu aplicarea permisiunilor de acces, înregistrarea operațiunilor în jurnalul de audit și gestionarea ciclului de acces la secrete prin operațiuni de checkout și check-in, fără a impune în mod obligatoriu existența unui SDK dedicat, a unui agent sau a unui plugin specializat pentru integrarea cu platformele CI/CD?
Răspuns (16 oct 2026, 11:35):
Da. Caietul de sarcini permite utilizarea unui API, SDK sau mecanism echivalent și nu impune existența obligatorie a unui SDK, agent sau plugin CI/CD dedicat.
Mecanismul trebuie să permită solicitarea secretelor la runtime, controlul accesului pe baza identității aplicației și a politicii, utilizarea unor identități API dedicate, restricționarea permisiunilor și auditarea operațiunilor. Cheia sau credențiala utilizată pentru accesarea API-ului trebuie să poată fi protejată și administrată astfel încât implementarea să nu reintroducă un secret static necontrolat în aplicație sau în fișierele de configurare.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 14:59
Subiectul întrebării:
Raportare, audit și integrare cu SIEM/ITSM.
Întrebare:
Corect să înțelegem că cerința privind raportarea, auditul și integrarea cu sistemele SIEM/ITSM poate fi considerată îndeplinită prin generarea programată a rapoartelor în formatele PDF, HTML și CSV, exportul jurnalelor de evenimente și transmiterea acestora către unul sau mai multe sisteme SIEM prin protocoale standard, precum syslog (UDP/TCP/TLS, RFC 3164/5424) și SNMP traps, iar integrarea cu sistemele ITSM poate fi realizată prin intermediul unui API REST, fără a fi obligatorie existența unui conector ITSM nativ dedicat?
Răspuns (16 oct 2026, 11:36):
Cerința poate fi îndeplinită prin rapoarte programate, cu condiția asigurării exportului cel puțin în formatele PDF și CSV. Formatul HTML constituie o funcționalitate suplimentară.
Integrarea SIEM poate fi realizată prin Syslog TCP, UDP sau TLS și prin alte mecanisme documentate. Integrarea ITSM poate fi realizată prin API REST sau conector documentat, fără obligativitatea unui conector nativ. Integrarea trebuie însă să permită inclusiv validarea automată a tichetului, acolo unde această funcție este solicitată. Simpla transmitere de evenimente către ITSM nu acoperă cerința de validare a tichetelor.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 14:59
Subiectul întrebării:
Separarea componentelor aplicației, bazei de date, gateway-urilor și stocării înregistrărilor.
Întrebare:
Este corect să înțelegem că cerința privind backupul și restaurarea configurației, a bazei de date, a cheilor critice și a celorlalte date necesare recuperării platformei poate fi considerată îndeplinită prin asigurarea exportului și importului configurației instanței, inclusiv a datelor necesare restaurării acesteia, precum și prin backupul datelor de sesiune, cu condiția asigurării unei proceduri documentate de recuperare a platformei?
Răspuns (16 oct 2026, 11:38):
Da, dacă mecanismul și procedura documentată permit restaurarea completă a platformei și acoperă configurația, baza de date, cheia principală sau materialul criptografic necesar decriptării seifului, precum și celelalte date necesare recuperării.
Backup-ul exclusiv al înregistrărilor de sesiune sau exportul parțial al configurației nu este suficient. Procedura de restaurare trebuie să poată fi demonstrată.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 14:59
Subiectul întrebării:
Backup și restaurare pentru configurație, baza de date, chei critice și datele necesare recuperării.
Întrebare:
Având în vedere că descoperirea automată și programată este disponibilă pentru conturile și serverele Active Directory, precum și pentru conturile locale de pe serverele Windows, iar celelalte tipuri de resurse pot fi integrate prin import CSV sau API REST, poate fi considerată cerința îndeplinită prin combinarea mecanismelor de discovery automat cu metodele alternative de inventariere și integrare a resurselor, fără a impune descoperirea automată nativă pentru fiecare categorie de resurse?
Răspuns (16 oct 2026, 11:43):
Nu. Descoperirea la cerere și programată reprezintă o cerință distinctă de onboarding-ul în masă prin import sau API.
Importul CSV și integrarea prin API sunt acceptate ca mecanisme complementare, dar nu înlocuiesc descoperirea la cerere și programată pentru resursele Windows, Linux/Unix, echipamentele de rețea și mediile virtualizate, precum și pentru bazele de date și serviciile cloud suportate. Ofertantul va indica distinct, în matricea de conformitate, mecanismul de descoperire utilizat pentru fiecare dintre aceste categorii.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:00
Subiectul întrebării:
Descoperire la cerere și programată a resurselor Windows/Linux/Unix, echipamentelor de rețea, bazelor de date, mediilor virtualizate și serviciilor cloud suportate.
Întrebare:
Având în vedere că descoperirea automată și programată este disponibilă pentru conturile și serverele Active Directory, precum și pentru conturile locale de pe serverele Windows, iar celelalte tipuri de resurse pot fi integrate prin import CSV sau API REST, poate fi considerată cerința îndeplinită prin combinarea mecanismelor de discovery automat cu metodele alternative de inventariere și integrare a resurselor, fără a impune descoperirea automată nativă pentru fiecare categorie de resurse?
In alt caz, rugăm sa descrieți mecanizmul.
Răspuns (16 oct 2026, 11:39):
Nu. Descoperirea la cerere și programată reprezintă o cerință distinctă de onboarding-ul în masă prin import sau API.
Importul CSV și integrarea prin API sunt acceptate ca mecanisme complementare, dar nu înlocuiesc descoperirea la cerere și programată pentru resursele Windows, Linux/Unix, echipamentele de rețea și mediile virtualizate, precum și pentru bazele de date și serviciile cloud suportate. Ofertantul va indica distinct, în matricea de conformitate, mecanismul de descoperire utilizat pentru fiecare dintre aceste categorii.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:00
Subiectul întrebării:
Descoperirea conturilor locale privilegiate, de domeniu, de serviciu și a altor conturi administrative de pe resursele suportate.
Întrebare:
Având în vedere că identificarea conturilor de domeniu și a conturilor locale privilegiate este disponibilă pentru resursele Windows suportate, iar conturile de serviciu pot fi identificate în Active Directory pe baza domeniilor de căutare configurate (Base DN / Group DN), poate fi considerată cerința îndeplinită prin clasificarea conturilor de domeniu în privilegiate și non-privilegiate și identificarea conturilor de serviciu în cadrul conturilor Active Directory.
Răspuns (16 oct 2026, 11:57):
Identificarea conturilor de domeniu și a conturilor de serviciu în Active Directory, prin filtre și domenii de căutare configurabile, este acceptată.
Ofertantul trebuie să demonstreze și descoperirea conturilor locale privilegiate de pe resursele Windows și Linux/Unix, precum și a conturilor de serviciu și a celorlalte conturi administrative disponibile pe resursele integrate în platformă. Clasificarea conturilor existente în Active Directory nu substituie descoperirea conturilor locale de pe sistemele țintă.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:00
Subiectul întrebării:
Definirea de atribute/câmpuri suplimentare pentru resurse și conturi, utilizabile la filtrare, organizare și raportare.
Întrebare:
Pentru o mai bună înțelegere a cerinței, vă rugăm să clarificați mecanismul de implementare avut în vedere pentru definirea atributelor/câmpurilor suplimentare pentru resurse și conturi
Răspuns (16 oct 2026, 11:58):
Mecanismul tehnic este la latitudinea producătorului. Rezultatul solicitat este posibilitatea administratorului de a defini atribute sau câmpuri suplimentare pentru resurse și conturi și de a le utiliza la filtrare, organizare, grupare și raportare.
Nu este suficientă existența unui câmp fix de descriere care nu poate fi utilizat în aceste operațiuni.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:01
Subiectul întrebării:
Definirea de atribute/câmpuri suplimentare pentru resurse și conturi, utilizabile la filtrare, organizare și raportare.
Întrebare:
Având în vedere că accesul temporar poate fi acordat prin mecanismul Just-in-Time, cu justificare obligatorie, aprobare din partea unuia sau mai multor responsabili, înregistrarea și arhivarea solicitărilor, precum și încheierea automată a sesiunii la expirarea perioadei aprobate, poate fi considerată cerința îndeplinită?
Răspuns (16 oct 2026, 11:48):
Da. Mecanismul descris este acceptat dacă poate fi configurat pentru situații de urgență și asigură justificarea, aprobarea, limitarea temporală, revocarea automată și auditul complet al accesului.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:01
Subiectul întrebării:
Definirea unuia sau mai multor aprobatori și posibilitatea de a aproba, respinge sau modifica solicitarea.
Întrebare:
Înțelegem corect cerința dacă procesul de aprobare permite configurarea numărului de aprobatori necesari, desemnarea persoanelor autorizate să voteze, aprobarea sau respingerea solicitării cu justificarea obligatorie a respingerii, precum și revocarea voturilor pentru solicitările active?
Răspuns (16 oct 2026, 12:06):
Mecanismul descris acoperă aprobarea și respingerea solicitării. Pentru conformitate integrală, trebuie demonstrată și posibilitatea modificării solicitării de către persoana autorizată, de exemplu modificarea intervalului, duratei sau a altor parametri ai accesului.
Revocarea unui vot nu este, prin ea însăși, echivalentă cu modificarea solicitării.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:02
Subiectul întrebării:
Revocarea automată a accesului la expirarea perioadei aprobate și posibilitatea configurării unei perioade de grație.
Întrebare:
Este corect că obiectivul principal este revocarea efectivă și automată a accesului la expirarea intervalului aprobat, realizată de FUDO PAM prin terminarea sesiunii? Perioada de grație configurabilă este obligatorie în toate cazurile sau poate fi considerată opțională dacă expirarea este aplicată strict și solicitările neutilizate expiră automat conform politicii produsului?
Răspuns (16 oct 2026, 12:08):
Revocarea automată a accesului la expirarea perioadei aprobate este obligatorie.
Posibilitatea configurării unei perioade de grație face parte din cerință. Beneficiarul trebuie să poată stabili valoarea acesteia, inclusiv valoarea zero. Un produs care aplică exclusiv o perioadă fixă, care nu poate fi configurată, nu îndeplinește integral cerința.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:02
Subiectul întrebării:
Posibilitatea auto-aprobării controlate pentru scenarii definite de beneficiar.
Întrebare:
Având în vedere că pot fi configurate scenarii de acces fără aprobare prealabilă, în baza unor intervale orare definite prin politica de acces zilnic sau prin autorizarea prealabilă a accesului pentru anumite resurse, poate fi considerată cerința îndeplinită prin aceste mecanisme de acces controlat fără aprobare, fără a impune posibilitatea auto-aprobării de către utilizator a propriei solicitări de acces?
Răspuns (16 oct 2026, 12:09):
Cerința nu presupune aprobarea de către utilizator a propriei solicitări.
Sunt acceptate mecanismele prin care platforma aprobă solicitarea pe baza unor reguli configurate de beneficiar, precum utilizatorul sau grupul, resursa, contul, intervalul, politica aplicabilă ori validarea unui tichet, cu păstrarea solicitării și a deciziei în audit.
Accesul permanent sau accesul acordat fără generarea și auditarea unei solicitări nu este considerat echivalent cu workflow-ul de auto-aprobare solicitat.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:03
Subiectul întrebării:
Posibilitatea validării automate a unui Ticket ID/Service Request într-un sistem ITSM integrat înainte de acordarea accesului și/sau utilizarea validării tichetului ca regulă de auto-aprobare.
Întrebare:
Având în vedere că sistemul ITSM/Service Desk permite gestionarea și aprobarea solicitărilor de acces, vă rugăm să clarificați care este scenariul operațional avut în vedere pentru integrarea validării automate a unui Ticket ID/Service Request cu soluția PAM. Este necesară verificarea automată a existenței și statutului tichetului înainte de acordarea accesului sau obiectivul principal este automatizarea procesului de aprobare? În acest context, poate fi acceptată utilizarea fluxurilor de aprobare și a politicilor de acces configurate în platforma PAM, fără validarea automată a tichetului ITSM și fără utilizarea acestuia ca regulă de auto-aprobare?
Răspuns (16 oct 2026, 12:11):
Cerința se menține. Soluția trebuie să poată verifica automat existența și/sau starea tichetului în sistemul ITSM înainte de acordarea accesului și/sau să utilizeze rezultatul validării ca regulă de auto-aprobare.
Fluxurile interne de aprobare ale platformei PAM, fără verificarea tichetului în sistemul ITSM, nu substituie această cerință. Integrarea poate fi realizată prin API sau conector documentat.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:03
Subiectul întrebării:
Actualizarea automată a dependențelor uzuale ale conturilor de serviciu după schimbarea parolei, inclusiv servicii Windows, task-uri programate, application pools și fișiere/configurații de aplicație care păstrează credențiale.
Întrebare:
Vă rugăm să clarificați cât de critică este pentru organizația dumneavoastră actualizarea automată a dependențelor conturilor de serviciu după schimbarea parolei și care sunt scenariile concrete avute în vedere (servicii Windows, task-uri programate, application pools, fișiere sau configurații de aplicație). În cazul în care această funcționalitate nu este disponibilă nativ în soluția PAM, poate fi acceptată ca excepție, cu condiția ca schimbarea parolelor conturilor de serviciu să fie gestionată prin proceduri operaționale alternative, care să asigure actualizarea dependențelor și continuitatea serviciilor?
Răspuns (16 oct 2026, 12:13):
Cerința este obligatorie și nu se acceptă substituirea acesteia exclusiv prin proceduri manuale.
Funcția poate fi realizată nativ sau prin scripturi, plugin-uri ori conectori incluși în ofertă, documentați și controlați de platformă. Ofertantul trebuie să demonstreze actualizarea dependențelor uzuale indicate în caietul de sarcini și menținerea sincronizării după schimbarea parolei.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:04
Subiectul întrebării:
Pentru extensiile de resetare care execută cod/script personalizat, soluția trebuie să permită un mecanism de control/validare administrativă înainte de utilizarea în producție.
Întrebare:
Vă rugăm să clarificați scopul și nivelul de criticitate al cerinței privind controlul și validarea administrativă a extensiilor de resetare care execută cod sau scripturi personalizate înainte de utilizarea acestora în mediul de producție. Este acest mecanism obligatoriu din perspectiva politicilor interne de securitate și conformitate sau poate fi acceptat ca excepție, în cazul în care soluția nu oferă nativ un astfel de mecanism, cu condiția ca validarea și aprobarea scripturilor să fie realizate prin proceduri administrative alternative înainte de implementare?
Răspuns (16 oct 2026, 12:15):
Cerința se menține. Pentru extensiile care execută cod sau script personalizat, platforma trebuie să permită un mecanism de control sau validare administrativă înainte de utilizarea în producție.
O procedură administrativă externă platformei, care nu împiedică utilizarea în producție a unei extensii nevalidate, nu constituie un mecanism tehnic echivalent.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:04
Subiectul întrebării:
Posibilitatea aprobării de către un al doilea administrator constituie un avantaj tehnic.
Întrebare:
Vă rugăm să clarificați în ce scenarii este necesară aprobarea unei acțiuni de către un al doilea administrator și cât de importantă este această funcționalitate pentru procesul operațional și pentru cerințele interne de securitate. Având în vedere că cerința este formulată ca un avantaj tehnic, poate fi acceptată ca excepție în cazul în care soluția nu oferă nativ această funcționalitate?
Răspuns (16 oct 2026, 12:16):
Aprobarea de către un al doilea administrator este formulată ca avantaj tehnic, nu ca cerință obligatorie. Lipsa acestei funcții nu determină neconformitatea ofertei, dacă mecanismul obligatoriu de control și validare administrativă este asigurat.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:05
Subiectul întrebării:
Notificări pentru eșecuri de rotație, neconcordanțe și alte evenimente relevante.
Întrebare:
Având în vedere că eșecurile de rotație a parolelor, expirările operațiunilor și neconcordanțele de verificare sunt înregistrate ca evenimente de tip WARNING/ERROR și pot fi transmise către o soluție SIEM prin syslog (UDP/TCP/TLS), unde pot fi configurate reguli de alertare și notificare, poate fi considerată cerința îndeplinită prin acest mecanism, fără a impune notificări prin e-mail native și dedicate pentru fiecare tip de eveniment legat de schimbarea secretelor?
Răspuns (16 oct 2026, 12:17):
Transmiterea evenimentelor WARNING/ERROR către SIEM este acceptată ca mecanism suplimentar de monitorizare și alertare, dar nu substituie cerința privind notificarea prin e-mail.
Platforma trebuie să poată genera notificări prin e-mail pentru evenimente relevante, inclusiv eșecuri de rotație și neconcordanțe, prin reguli sau politici configurabile. Nu este obligatorie existența unui tip distinct și predefinit de notificare pentru fiecare eveniment.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:05
Subiectul întrebării:
Monitorizarea suplimentară, prin agent, a sesiunilor directe/neintermediate pe sistemele Windows selectate constituie o funcționalitate suplimentară acceptată, dacă este inclusă în ofertă.
Întrebare:
Vă rugăm să clarificați scenariile operaționale în care este necesară monitorizarea suplimentară, prin agent, a sesiunilor directe/neintermediate pe sistemele Windows selectate.
În special, vă rugăm să precizați:
- dacă accesul direct la sistemele Windows, în afara platformei PAM, este permis în cadrul infrastructurii beneficiarului;
- dacă obiectivul principal este identificarea conexiunilor care ocolesc platforma PAM, monitorizarea activităților utilizatorilor sau înregistrarea completă a sesiunilor;
- dacă această funcționalitate este obligatorie pentru toate sistemele Windows sau doar pentru anumite servere critice;
- dacă poate fi acceptată o abordare alternativă, bazată pe restricționarea tehnică a accesului direct la sistemele respective și permiterea accesului privilegiat exclusiv prin platforma PAM, completată de mecanismele existente de audit și monitorizare.
Menționăm că, în urma analizei soluțiilor identificate, funcționalitatea specifică de monitorizare suplimentară, prin agent, a sesiunilor directe/neintermediate pe sistemele Windows este documentată în oferta ManageEngine PAM360. În acest context, având în vedere că cerința este formulată ca o funcționalitate suplimentară, acceptată dacă este inclusă în ofertă, vă rugăm să confirmați dacă aceasta poate fi considerată opțională și acceptată ca excepție, în cazul în care accesul direct este restricționat tehnic, iar obiectivele de securitate și audit sunt asigurate prin mecanisme alternative.
Răspuns (16 oct 2026, 12:20):
Funcționalitatea este formulată ca funcționalitate suplimentară acceptată și nu constituie condiție obligatorie de conformitate. Lipsa acesteia nu determină neconformitatea ofertei.
Beneficiarul nu comunică în cadrul procedurii informații suplimentare privind politicile interne de acces sau sistemele pentru care ar putea fi utilizată această capabilitate.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:06
Subiectul întrebării:
Elevarea temporară a conturilor Windows/Windows Domain prin atribuirea controlată a unor drepturi sau a unor apartenențe la grupuri locale/de securitate ori printr-un mecanism echivalent.
Întrebare:
Vă rugăm să clarificați scenariile operaționale în care este necesară elevarea temporară a conturilor Windows/Windows Domain prin atribuirea sau modificarea temporară a drepturilor și a apartenenței la grupuri locale/de securitate, precum și nivelul de criticitate al acestei funcționalități pentru organizația dumneavoastră.
Obiectivul principal este modificarea temporară a privilegiilor direct în sistemele Windows/Active Directory sau poate fi acceptat și un mecanism echivalent de acces privilegiat Just-in-Time, prin care utilizatorului i se acordă acces limitat în timp la un cont privilegiat, printr-o sesiune controlată și injectarea automată a credențialelor, fără ca utilizatorul să dețină permanent privilegiile respective?
În cazul în care modificarea dinamică a apartenenței la grupuri nu este obligatorie, poate fi acceptată ca excepție lipsa acestei funcționalități native, cu condiția asigurării accesului privilegiat temporar, controlat și auditat prin mecanisme alternative?
Răspuns (16 oct 2026, 12:21):
Cerința poate fi îndeplinită prin atribuirea temporară de drepturi sau apartenențe la grupuri ori printr-un mecanism echivalent de elevare temporară.
Accesul limitat în timp la un cont privilegiat permanent, prin injectarea credențialelor, este o funcție de acces privilegiat și management al sesiunii, dar nu constituie, prin el înseși, elevare temporară sau Zero Standing Privileges, deoarece privilegiile contului țintă rămân permanente.
Mecanismul echivalent trebuie să acorde temporar privilegiile necesare identității utilizatorului sau unui cont creat ori activat temporar și să asigure retragerea automată a acestora la check-in, la expirare sau la încheierea sesiunii.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:06
Subiectul întrebării:
Executarea controlată a aplicațiilor sau scripturilor aprobate pe Windows cu privilegii ridicate, fără divulgarea credențialelor privilegiate.
Întrebare:
Vă rugăm să clarificați dacă cerința privind executarea controlată a aplicațiilor sau scripturilor aprobate cu privilegii ridicate presupune în mod obligatoriu elevarea privilegiilor direct pe stația de lucru Windows a utilizatorului sau dacă poate fi acceptat și un mecanism echivalent, prin publicarea aplicațiilor aprobate ca RemoteApp pe un server RDP/RDS accesibil prin platforma PAM, cu transmiterea securizată a credențialelor privilegiate, fără ca acestea să fie dezvăluite utilizatorului, și cu posibilitatea restricționării accesului exclusiv la aplicațiile autorizate?
În cazul în care obiectivul principal este executarea controlată a aplicațiilor și protejarea credențialelor privilegiate, poate fi acceptată această abordare ca alternativă conformă, fără a impune obligatoriu executarea locală a aplicațiilor cu privilegii ridicate pe stația de lucru?
Răspuns (16 oct 2026, 11:22):
Caietul de sarcini nu impune executarea aplicației pe stația locală a utilizatorului.
Mecanismul RemoteApp poate fi acceptat ca echivalent dacă ofertantul demonstrează cumulativ executarea aplicațiilor sau scripturilor aprobate cu privilegii ridicate, cu efect asupra sistemului țintă pentru care este necesară operațiunea privilegiată, nedivulgarea credențialelor, restricționarea execuției exclusiv la aplicațiile autorizate, inclusiv prevenirea lansării altor aplicații, a interpretoarelor de comenzi sau a altor procese neautorizate din cadrul aplicației publicate, validarea aplicațiilor prin nume, cale, semnătură digitală, hash sau criteriu echivalent și auditarea operațiunilor.
Simpla publicare a unui desktop sau a unei aplicații prin RDP, fără validarea aplicației și fără restricțiile solicitate, nu este suficientă.
Cerințele caietului de sarcini nu se modifică.
Mentenanța PAM
Data:
15 oct 2026, 15:07
Subiectul întrebării:
Notificări pentru eșecuri de rotație, neconcordanțe și alte evenimente relevante.
Întrebare:
Este acceptabil ca evenimentele de eșec al rotației, timeout și neconcordanță să fie înregistrate ca WARNING/ERROR și transmise către SIEM prin syslog pentru alertare, chiar dacă nu există un tip separat de notificare e-mail în produs? Poate fi utilizat SIEM-ul beneficiarului pentru generarea alertelor în timp real pe baza acestor evenimente?
Răspuns (16 oct 2026, 12:19):
Transmiterea evenimentelor WARNING/ERROR către SIEM este acceptată ca mecanism suplimentar de monitorizare și alertare, dar nu substituie cerința privind notificarea prin e-mail.
Platforma trebuie să poată genera notificări prin e-mail pentru evenimente relevante, inclusiv eșecuri de rotație și neconcordanțe, prin reguli sau politici configurabile. Nu este obligatorie existența unui tip distinct și predefinit de notificare pentru fiecare eveniment.
Cerințele caietului de sarcini nu se modifică.
Doar utilizatorii autorizați ai platformei pot să adreseze întrebări în perioada de clarificări.
Document semnat cu succes
OK