Mentenanța PAM

15 окт 2026, 14:57

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.

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.

15 окт 2026, 14:58

Integrare cu infrastructura de identitate, sistemele ITSM și SIEM, precum și cu instrumentele de automatizare.

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?

15 окт 2026, 14:58

Controlul aplicațiilor/comenzilor privilegiate pe sistemele suportate.

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?

15 окт 2026, 14:58

API și mecanisme pentru eliminarea secretelor hard-coded din aplicații și scripturi.

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?

15 окт 2026, 14:59

Raportare, audit și integrare cu SIEM/ITSM.

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?

15 окт 2026, 14:59

Separarea componentelor aplicației, bazei de date, gateway-urilor și stocării înregistrărilor.

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?

15 окт 2026, 14:59

Backup și restaurare pentru configurație, baza de date, chei critice și datele necesare recuperării.

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?

15 окт 2026, 15:00

Descoperire la cerere și programată a resurselor Windows/Linux/Unix, echipamentelor de rețea, bazelor de date, mediilor virtualizate și serviciilor cloud suportate.

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.

15 окт 2026, 15:00

Descoperirea conturilor locale privilegiate, de domeniu, de serviciu și a altor conturi administrative de pe resursele suportate.

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.

15 окт 2026, 15:00

Definirea de atribute/câmpuri suplimentare pentru resurse și conturi, utilizabile la filtrare, organizare și raportare.

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

15 окт 2026, 15:01

Definirea de atribute/câmpuri suplimentare pentru resurse și conturi, utilizabile la filtrare, organizare și raportare.

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ă?

15 окт 2026, 15:01

Definirea unuia sau mai multor aprobatori și posibilitatea de a aproba, respinge sau modifica solicitarea.

Î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?

15 окт 2026, 15:02

Revocarea automată a accesului la expirarea perioadei aprobate și posibilitatea configurării unei perioade de grație.

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?

15 окт 2026, 15:02

Posibilitatea auto-aprobării controlate pentru scenarii definite de beneficiar.

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?

15 окт 2026, 15:03

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.

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?

15 окт 2026, 15:03

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.

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?

15 окт 2026, 15:04

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.

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?

15 окт 2026, 15:04

Posibilitatea aprobării de către un al doilea administrator constituie un avantaj tehnic.

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?

15 окт 2026, 15:05

Notificări pentru eșecuri de rotație, neconcordanțe și alte evenimente relevante.

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?

15 окт 2026, 15:05

Monitorizarea suplimentară, prin agent, a sesiunilor directe/neintermediate pe sistemele Windows selectate constituie o funcționalitate suplimentară acceptată, dacă este inclusă în ofertă.

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.

15 окт 2026, 15:06

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.

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?

15 окт 2026, 15:06

Executarea controlată a aplicațiilor sau scripturilor aprobate pe Windows cu privilegii ridicate, fără divulgarea credențialelor privilegiate.

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?

15 окт 2026, 15:07

Notificări pentru eșecuri de rotație, neconcordanțe și alte evenimente relevante.

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?