Sectiunea II caietul de sarcini

4.3Componente Software

4.3.1Componenta Portal

4.3.1.1Cerinte generale

Solutia va dipune de o platforma de tip Portal Server care va indeplini urmatoarele functionalitati:

• 
  Managementul continutului Web – Platforma Portal trebuie sa ofere instrumente adecvate pentru managementul continutului web in vederea crearii de pagini web personalizate.
  

• 
  Managementul documentelor electronice – Componenta Portal Server trebuie sa ofere instrumente de tip Document Management in vederea gestionarii documentelor electronice vehiculate.
  

• 
  Creare si management de fluxuri de lucru – Platforma Portal va asigura unelte pentru managementul fluxurilor de lucru in vederea gestionarii fluxurilor necesare.
  

• 
  Facilitati de colaborare – Platforma Portal va dispune de facilitati de colaborare avansate pentru a sprijini cat mai eficient interactiunea utilizatorilor.
  

4.3.1.2Caracteristici minimale ale platformei

A)Cerinte de tehnologie

• 
  Sa ofere suport pentru tehnologii si standarde deschise;
  
• 
  Sa ofere suport multi-lingvistic pentru instalare si prezentare;
  
• 
  Sa ofere suport multi-home pentru instalarea de servere multiple pe aceeasi masina fizica;
  
• 
  Sa fie compatibil cu standardele platformei Java Enterprise Edition (J2EE) sau echivalenta;
  
• 
  Sa permita instalarea dinamica de aplicatii web, aplicatii J2EE si servicii web (web Services);
  
• 
  Sa ofere posibilitatea de creare a portalurilor personalizate, managementul continutului portalului si publicarea in portal de tip Self-Service;
  
• 
  Sa ofere suport pentru tehnologie de tip Portlet conform standardului JSR 168, JSR 286;
  
• 
  Sa ofere suport pentru standard WSRP pentru integrare usoara a portletilor remote, aplicatiilor si a continutului;
  
• 
  Sa ofere Portlet-i predefiniti care sa permita importul de continut din diferite surse de date - baze de date, fisiere, pagini web, servicii web;
  
• 
  Sa ofere continut personalizat de baza si personalizare avansata dependenta de context;
  
• 
  Sa permita definirea layout-ului si a resurselor Portal dintr-un browser web;
  
• 
  Sa implementeze mecanisme de control al accesului la resurse la nivel de utilizator, grup sau rol;
  
• 
  Sa se integreze cu cel putin o solutie de tip Single-Sign On pentru autentificarea unitara a utilizatorilor;
  
• 
  Sa permita accesarea aplicatiei din browsere traditionale (Internet Explorer, Mozilla, Netscape Navigator, etc.) cat si de pe dispozitive mobile (PDA, Palm, etc.);
  
• 
  Sa ofere scalabilitate pentru deservirea unui numar cat mai mare de utilizatori;
  
• 
  Sa poata fi instalat pe un server de aplicatii cu capabilitati de clustering, balansare si failover;
  
• 
  Sa ofere suport multi-site, multi-portal pentru aplicatii distincte instalate pe aceeasi masina fizica;
  
• 
  Solutia de tip portal trebuie sa ofere un mecanism de tip asistent (wizard) pentru crearea automata a site-urilor pe baza unor sabloane.
  

B)Flexibilitate

Flexibilitatea Platformei de tip portal va fi asigurata utilizand produse software compatibile cu cat mai multe sisteme de operare, baze de date, limbaje de programare pentru a evita situatiile in care Autoritatea Contractanta va depinde exclusiv de anumiti furnizori pentru operatiunile ulterioare care vor viza modificari privind functionalitatile, mentenanta, etc.
Astfel, platforma de tip Portal utilizata trebuie sa raspunda urmatoarelor cerinte:

• 
  Neutralitatea fata de Sisteme de Operare:
  

Platforma de tip Portal trebuie sa suporte multiple sisteme de operare, atat 32 biti cat si 64 biti si anume:

• 
  Windows Server
  
• 
  Linux (cel putin doua distributii majore ca Red Hat, Ubuntu ,Suse, Slakware)
  
• 
  Solaris
  

• 
  Neutralitatea fata de sisteme de Baze de date:
  

In vederea asigurarii flexibilitatii tehnologice, platforma tip Portal trebuie sa suporte cel putin urmatoarele sisteme de gestionare a bazelor de date:

• 
  MS SQL Server
  
• 
  IBM DB2
  
• 
  Oracle Database
  

• 
  Neutralitatea fata de platforme tehnologice si limbaje de programare:
  

Portalul trebuie sa suporte multiple tehnologii si limbaje ca:

• 
  Java
  
• 
  Apache
  
• 
  Tomcat
  
• 
  Ruby
  
• 
  PHP
  
• 
  Python
  

C)Scalabilitate si extensibilitate

• 
  Platforma Portal trebuie sa suporte configuratia de tip “Cluster” pentru a permite adaugarea de masini hardware in cazul cresterii rapide a volumului de date si tranzactii, fara a fi nevoie de inlocuirea echipamentelor hardware existente.
  

• 
  Platforma Portal trebuie sa permita adaugarea ulterioara de module si functionalitati folosind cat mai putina scriere de cod si fara a fi nevoie de reproiectarea modulelor existente. Platforma Portal trebuie sa dispuna de instrumente vizuale de dezvoltare de tip “Drag & Drop”.
  

D)Functionalitati predefinite ale platformei portal

• 
  Portalul trebuie sa permita comunitatilor de utilizatori sa-si poata asocia propriile customizari, layout-uri.
  
• 
  Portalul trebuie sa dispuna de facilitati incorporate de Management al Documentelor care sa permita:
  

• 
  Stocarea fisierelor;
  
• 
  Gestionarea Directoarelor;
  
• 
  Posibilitatea adaugarii de tag-uri;
  
• 
  Posibilitatea de afisare fara a permite copierea (display only);
  
• 
  Instrumente de Cautare.
  

• 
  Portalul trebuie sa dispuna de facilitati incorporate de Management al continutului Web care sa asigure:
  

• 
  Crearea de continut web si publicarea acestuia pe Portal;
  
• 
  Editor Web;
  
• 
  Crearea de Template-uri;
  
• 
  Posibilitati de adaugare de metadate;
  
• 
  Versionare;
  
• 
  Instrumente de Cautare;
  

• 
  Portalul trebuie sa puna la dispozitie instrumente incorporate de creare a fluxurilor de lucru in vederea crearii si customizarii fluxurilor de lucru necesare.
  
• 
  Portalul trebuie sa dispuna de instrumente vizuale de Design Web capabile sa realizeze rapid pagini web folosind sabloane existente. Astfel fiecare institutie publica va fi capabila sa-si construiasca pagina Web disponibile cetatenilor fara a fi nevoit sa apeleze la personal specializat in scrierea de cod.
  
• 
  Portalul trebuie sa dispuna de instrumente colaborative predefinite : Forum si Instant Messaging.
  

E)Cerinte de securitate ale platformei portal

• 
  Portalul trebuie sa dispuna de instrumente proprii de management al utilizatorilor, grupurilor de utilizatori, permisiunilor si comunitatilor de utilizatori.
  
• 
  Platforma Portal trebuie sa dispuna de mecanisme de autentificare si acordare de permisiuni cu granularitate fina, si anume:
  

• 
  Sa asigure posibilitatea de a asigna permisiuni si roluri pentru utilizatori, grupuri de utilizatori, comunitati si organizatii de utilizatori.
  

• 
  Portalul trebuie sa fie capabil sa afiseze continutul adecvat profilului utilizatorului care il acceseaza. Continutul afisat va fi relationat cu caracteristicile de securitate asociate utilizatorului autentificat.
  
• 
  Platforma Portal trebuie sa ofere posibilitatea utilizarii de produse de tip LDAP cum ar fi:
  

• 
  Microsoft Active Directory;
  
• 
  Novell eDirectory;
  
• 
  Sun Java System Directory;
  
• 
  Tivoli Directory Server
  

• 
  Platforma Portal trebuie sa permita autentificarea utilizatorilor folosind Open ID. Mai multe informatii referitoare la OpenID sunt disponibile la: http://openid.net
  

F)Prezentare si navigare

• 
  Este necesar ca interfata portalului sa fie separata, din punct de vedere logic, de codul aplicatiei, asa incat in cazul actualizarii aplicatiei, sa se pastreze toate particularizarile ce fusesera efectuate asupra interfetei;
  
• 
  Trebuie sa existe servicii de prezentare care sa permita particularizarea interfetei pentru fiecare sablon de lucru sau rol din echipa.
  
• 
  Utilizatorii trebuie sa poata vizualiza, crea, converti sau edita documente, tabele de calcul si fisiere tip prezentare, direct din mediul de lucru portal, fara a avea nevoie de instrumente aditionale
  
• 
  Sistemul trebuie sa se ofere suport pentru crearea de portaluri virtuale, asa incat sa se implementeze rapid sisteme aditionale tip portal, peste infrastructura existenta. Astfel se va utiliza o singura instalare de portal, peste care vor rula mai multe sisteme de portal diferite, cu URL-uri de acces diferite, grupuri de utilizatori diferite, elemente grafice pentru intrefata diferite.
  

G)Publicarea si Gestiunea continutului

• 
  Solutia trebuie sa includa un instrument pentru publicarea de continut, pentru a permite utilizatorilor privilegiati sa publice, sa actualizeze sau sa stearga propriile pagini, intr-un mod simplu si facil;
  
• 
  Solutia trebuie sa ofere o modalitate simpla de administrare centralizata, atat pentru administratorii de continut cat si pentru cei care aproba continutul;
  
• 
  Pentru continutului publicat trebuie sa se stocheze data publicarii, data la care trebuie arhivat si data la care documentul respectiv nu mai este valabil, cu scopul de a permite adaugari sau stergeri automate;
  
• 
  Accesul la continutul se va face functie de utilizatorul care vizualizeaza datele spre exemplu, companiile externe organizatiei vor avea drepturi de acces la un continut mai restrans;
  
• 
  Formatarea continutului trebuie realizata pe baza de sabloane (template-uri);
  
• 
  Solutia trebuie sa ofere capabilitati de control al versiunilor si arhivare;
  
• 
  Solutia trebuie sa ofere posibilitatea de a extrage continut direct din baza de date;
  
• 
  Continutul documentelor tip Word sau Excel sau a prezentarilor PowerPoint trebuie sa poata fi integrat in mod simplu in sistemul de portal, prin portleti, fara ca utilizatorii care vizualizeaza continutul acestor documente sa fie nevoiti sa aiba instalate produsele Microsoft Office pe statiile de lucru;
  
• 
  Portalul trebuie sa ofere suport pentru documente in format PDF;
  
• 
  Interfata cu utilizatorul trebuie sa ofere asistenta pentru formatarea documentelor, astfel incat utilizatorii fara cunostinte de HTML sa poata contribui la publicarea de informatii;
  
• 
  Solutia trebuie sa suporte structuri ierarhice de navigare arborescenta pentru documente;
  
• 
  Documente trebuie sa fie securizate fara a exista posibilitatea a fi accesate in absenta autentificarii;
  
• 
  Solutia trebuie sa asigure ca structura de stocare este separata de structura de navigare printre documente (navigarea in site nu trebuie sa reflecte in mod necesar modul de clasificare si stocare al documentelor);
  
• 
  Solutia trebuie sa ofere capabilitati de publicare si personalizare de continut direct dintr-un browser web;
  
• 
  Subsistemul de publicare de continut trebuie sa includa capabilitati de flux de aprobare de documente.
  

H)Personalizare avansata

• 
  Solutia va oferi capabilitati de publicare si personalizare de continut direct dintr-un browser web;
  
• 
  Vor fi predefinite mai multe stiluri de organizare si prezentare a paginilor de portal. Dintre aceste stiluri predefinite va fi permisa alegerea unui stil personal de prezentare de catre utilizator;
  
• 
  Continutul accesat prin portal va fi automat afisat sau ascuns, pe baza rolurilor predefinite ale utilizatorilor;
  
• 
  Administratorii de portal trebuie sa poata controla drepturile utilizatorilor de a particulariza propriile pagini, functie de rolul acestora, sau functie de regulile definite;
  
• 
  Accesul la serviciile online se va face în functie de utilizatorul care acceseaza aceste servicii;
  
• 
  Solutia va suporta structuri ierarhice de navigare arborescenta.
  

4.3.2Componenta Server de Aplicatii

Caracteristicile minime pe care le va indeplini aceasta componenta sunt urmatoarele:

• 
  Trebuie sa indeplineasca normele Java EE 5;
  
• 
  Trebuie sa aiba capabilitati avansate de administrare centralizata;
  
• 
  Trebuie sa suporte scripturi de server pentru limbaje precum JavaScript si JRuby;
  
• 
  Trebuie sa contina unelte de dezvoltare pentru aplicatii Java EE 5;
  
• 
  Trebuie sa aiba posibilitatea dezvoltarii de aplicatii Web 2.0, SIP, SCA, SDO, si JPA;
  
• 
  Trebuie sa includa urmatoarele API-uri:
  

• 
  Java API pentru XML Messaging (JAXM);
  
• 
  Java API pentru XML Processing (JAXP);
  
• 
  Java API pentru XML Registries (JAXR);
  
• 
  Java API pentru XML-based Remote Procedure Call (JAX-RPC).
  

• 
  Trebuie sa suporte SOAP (Simple Object Access Protocol) si WSDL (Web Services Description Language);
  
• 
  Trebuie sa fie suportat pe cel putin o platforma Windows, cel putin doua distributii de Linux si cel putin o distributie de Unix;
  
• 
  Suport pentru Java SDK pe toate platformele sistemelor de operare suportate, incluzand Linux, UNIX si Microsoft Windows;
  
• 
  Trebuie sa suporte urmatoarele standarde de securitate:
  

• 
  Single Socket Layer (SSL)v2
  
• 
  SSLv3
  
• 
  Transport Layer Security (TLS) 1.0
  
• 
  X.509 certificates
  
• 
  Public Key Cryptography Standards (PKCS) #11
  
• 
  Federal Information Processing Standards (FIPS)-140
  

• 
  Sa ofere support pentru specificatiile de portlet JSR 168;
  
• 
  Suport pentru standardul SIP (Session Initiation Protocol) ce va permite implementarea de servicii de comunicare, prezenta sau mesagerie;
  
• 
  Suport XML complet;
  
• 
  Autentificare si autorizare avansata, precum JAAS si extensia Java cryptology (JCE) pentru securitate sporita;
  
• 
  Sa ofere posibilitatea de optimizare a timpului de raspuns al aplicatiilor prin mecanisme de preincarcare (cashing) a continutului static si dinamic.
  

4.3.3Componenta Server de Web

Caracteristicile minime pe care le va indeplini aceasta componenta sunt urmatoarele:

• 
  Trebuie sa aiba interfata de administrare in linie de comanda;
  
• 
  Trebuie sa suporte mecanisme de retentie sesiuni de lucru;
  
• 
  Trebuie sa asigure suport pentru management de continut WebDAV;
  
• 
  Trebuie sa asigure compresie HTTP;
  
• 
  Trebuie sa asigure suport pentru servere virtuale;
  
• 
  Trebuie sa asigure protectia impotriva amenintarilor comune;
  
• 
  Trebuie sa aigure suport pentru criptarea datelor si securitate folosind mecanisme SSL;
  
• 
  Trebuie sa aiba suport pentru protocolul FastCGI;
  
• 
  Trebuie sa aiba suport pentru arhitectura pe 64 de biti.
  

4.3.4Componenta Baze de date

Componenta de baze de date trebuie sa ofere urmatoarele facilitati minime:

• 
  Din punct de vedere al driverilor suportati, component de baze de date trebuie sa suporte urmatoarele tipuri de driveri:
  

• 
  Native C Library ;
  
• 
  ODBC, JDBC;
  
• 
  .NET ;
  
• 
  Community Drivers for PHP, Perl, Python, Ruby;
  

• 
  Partitionare, pentru imbunatatirea performantelor si administrarea bazelor de date foarte mari;
  
• 
  Replicare la nivel de rand, pentru imbunatatirea securitatii replicarii;
  
• 
  Instrument de tipul “event scheduler” pentru programarea executiei a diverse activitati asupra bazelor de date;
  
• 
  Suport pentru tranzactii de tipul “ACID” - (Atomicity, Consistency, Isolation, Durability) – pentru constructia de aplicatii securizate;
  
• 
  Suport pentru “proceduri stocate”, pentru imbunatatirea productivitatii dezvoltatorilor;
  
• 
  Suport pentru “triggeri”, in scopul definirii de reguli complexe de business la nivelul bazei de date;
  
• 
  Suport pentru “view-uri”, in scopul oferirii de posibilitati pentru vizualizarea datelor sensitive fara compromiterea (modificarea) acestora;
  
• 
  Inbstrument de tip “Information schema”, pentru accesul facil la metadata;
  
• 
  Respecta standardul “XA” in privinta tranzactiilor distribuite, pentru suportul tranzactiilor complexe peste baze de date multiple;
  
• 
  Suport pentru historizarea datelor si auditul acestora.
  

4.3.5Componenta Software Antivirus

Serverele care vor gazdui solutia vor fi prevazute cu o solutie de protectie de tip “Antivirus” in vederea protejarii sistemelor. Solutia de protectie de tip “Antivirus” trebuie sa indeplineasca urmatoarele cerinte:

4.3.5.1Cerinte generale:

• 
  Detectia si dezinfectia atat a virusilor internationali cat si a celor regionali (Europa de Est);
  
• 
  Producatorul trebuie fie certificat ISO 9001 pentru productie de software;
  
• 
  Certificari internationale obtinute cel tarziu in intervalul 2005 - 2008 (ICSA Labs, Checkmark, Virus Bulletin, CheckVir etc);
  
• 
  Posibilitatea de update centralizat a antivirusului atat automat cat si programat; update-ul de semnaturi de virusi va fi realizat de producator cel putin zilnic la un interval de maxim 1 ora;
  
• 
  Asigurarea si garantarea actualizarii semnaturilor de virus si upgrade la noi versiuni pe intrega perioada care se va contracta, cu posibilitati de prelungire contra cost dupa ce perioada initiala de mentenanta expira;
  
• 
  Toate produsele antivirus livrate vor apartine aceluiasi producator;
  
• 
  Produsele oferite vor avea valabilitate 3 ani.
  

4.3.5.2Cerinte privind serviciile si echipa de suport tehnic:

• 
  Avertizari prin e-mail asupra aparitiei noilor virusi
  
  • 
    Mesaje de alerta in cazul aparitiei unor noi virusi distructivi sau cu potential mare de rapandire rapida
    
• 
  Antidot pentru orice virus nou semnalat de catre beneficiar in maximum 24 ore de la aparitie;
  

• 
  Training pentru utilizarea/configurarea si administrarea solutiei de securizare LAN/WAN si probleme generale legate de virusologia IT. Training-ul se va efectua la locatia furnizorului de produse antivirus;
  
• 
  Asistenta tehnica telefonica si remote la configurarea produselor pentru locatiile din Bucuresti si din teritoriu in cazul in care aceasta se solicita. Asistenta tehnica va fi oferita contra cost de catre oameni certificati;
  
• 
  Personalul care va asigura interventiile la cerere trebuie sa fie certificat de producatorul solutiei.
  

4.3.5.3Cerinte specifice privind produsele antivirus

• 
  Protectie antivirus, antispyware si antirootkit;
  
• 
  Sa detecteze si sa protejeze impotriva virusilor, virusilor de tip file infector, virusilor de boot, virusilor polimorfici, virusilor de macro, scripturilor malitioase, cailor troieni, viermilor, „bots", „backdoors";
  
• 
  Sa detecteze si sa protejeze impotriva aplicatiilor de tip adware si spyware si a atacurilor „phishing";
  
• 
  Detectare si stergere avansata a rootkit-urilor prin tehnologia VxMS;
  
• 
  Actualizarea antivirus sa poata fi facuta automat la un interval de maxim 1 ora, on demand astfel incat sa nu existe brese de timp intre aparitia semnaturilor de virusi aparute pe site-ul producatorului si momentul actualizarii serverului de fisiere;
  
• 
  Folosirea tehnologiei TruScan Proactive Threat Scan pentru a contoriza comportarea buna sau rea a aplicatiilor necunoscute, imbuntatind in acest fel detectarea si reducand falsele pozitivele fara a fi necesara crearea de configuratii bazate pe reguli;
  
• 
  Scanare in timp real a fisierelor ce trec prin server, atat la deschiderea acestora cat si la inchidere; posibilitatea scanarii la cerere si a serverului pe care este instalat;
  
• 
  Sa ofere protectie in timp real, prin scanarea permanenta a activitatii desfasurate pe sistem, inclusiv aplicatiile lansate de utilizator sau configurate sa fie lansate automat de catre sistem;
  
• 
  Sa asigure protectia sistemului prin scanarea pe 3 niveluri:
  

• 
  Manuala
  
• 
  Programata
  
• 
  Continua
  

• 
  Sa ofere suport pentru detectia euristica si detectia prin emularea comportamentului virusilor;
  
• 
  Sa ofere suport pentru controlul accesului la retea al statiilor de lucru in baza unor politici pre-stabilite;
  
• 
  Cu ajutorul unei baze de date complete cu semnaturi de spyware si a euristicii de detectie a acestui tip de programe, produsul va trebui sa ofere protectie anti-spyware si sa permita prevenirea furtului de date confidentiale;
  
• 
  Administrare sa poata fi facuta centralizat din cadrul consolei de management globale sau independent;
  
• 
  Folosirea unei singure interfete pentru managementul tuturor tehnologiilor utilizate;
  
• 
  Posibilitatea scanarii la alegere doar a fisierelor avand extensiile specificate de administrator precum si optiunea de scanare numai a fisierelor de o dimensiune mai mica decat o limita stabilita de administrator;
  
• 
  Trimiterea automata si manuala fisierele suspecte catre laboratorul de analiza al producatorului;
  
• 
  Posibilitati de actiuni multiple la detectia unui virus (disinfect, delete, mutare in carantina);
  
• 
  Produsul se va integra in cadrul consolei de management unitar al solutiei antivirus;
  

• 
  Produsul este compatibil cu sisteme de operare Red Hat Enterprise Linux 3.x, 4.x, 5.x , SuSE Linux Enterprise (server/desktop) 9.x, 10.x, Novell Open Enterprise Server (OES/OES2), VMWare ESX 2.5, 3.x, Ubuntu 7.x, 8.x , Debian 4.x;
  
• 
  Posibilitatea produsului de a monitoriza disponibilitatea propriilor module in vederea verificarii functionalitatii acestora;
  
• 
  Cel putin 2 certificari pentru doua distributii diferite de Linux;
  

4.3.6Componenta Plata Online

Componenta "Plata Online » va realiza functionalitatile aferente efectuarii platilor online necesare modulelor e-Romania. Solutia tehnica trebuie sa permita operatii de plata online in urmatoarele conditii:

• 
  Sa poata comunica in mod securizat cu serverele payment gateway folosind RSA/SHA1, MD5 si HMAC,
  
• 
  Sa poata genera stringuri compatibile cu solutiile operatorilor de plati online cu carduri de credit,
  
• 
  Sa asigure transmitere de date server-to-server,
  
• 
  Sa poata fi interfatata cu sistemele 3DSecure,
  
• 
  Sa ofere posibilitatea de a monitoriza tranzactiile pentru administratorii operatorului de plati,
  
• 
  Sa ofere module API (Application Protocol Interface) necesare pentru interfatari;
  
• 
  Sa permita interfatarea ulterioara cu sistemele electronice ale emitentilor de plata,
  
• 
  Sa permita interfatarea ulterioara cu sistemele electronice ale beneficiarilor de plata;
  
• 
  Sa emita dovezi electronice valabile juridic in Romania, dovezi semnate cu certificate calificate de semnatura electronica,
  
• 
  Sa ofere o interfata web tuturor categoriilor de utilizatori,
  
• 
  Comunicarea intre module si comunicarea cu utilizatorii sistemului sa se faca intr-un mod securizat,
  
• 
  Sa ofere facilitati de arhivare - atat periodica cat si la comanda - a informatiilor,
  
• 
  Sa fie scalabila, permitand atat scalarea pe orizontala cat si cea pe verticala, fara modificari in cod,
  
• 
  Sa suporte un volum de tranzactii mediu de 4000 de tranzactii zilnic si un volum de varf de 20 de tranzactii pe secunda,
  
• 
  Sa contina un modul care sa permita interactiunea cu utilizatorii, obtinerea de feedback si managementul relatiei cu platitorii si beneficiarii.
  
• 
  Toate tranzactiile vor avea un timestamp si un identificator unic care va certifica data efecturarii tranzactiei si unicitatea acesteia.
  
• 
  Sistemul oferit trebuie sa permita accesul tuturor cetatenilor la sistemele de plata a taxelor, amenzilor si impozitelor in timp real si fara instalarea pe calculatoarele utilizatorilor a unor aplicatii suplimentare.
  
• 
  Solutia trebuie sa permita procesarea urmatoarelor tipuri de carduri: procesate urmatoarele tipuri de carduri:
  

• 
  VISA
  
• 
  VISA ELECTRON
  
• 
  MasterCard
  
• 
  Maestro
  
• 
  American Express (AMEX)
  

• 
  Sistemul oferit trebuie sa fie perfect interfatabil cu Ghiseul Virtual de plati al Guvernului Romaniei
  
• 
  Sistemul oferit trebuie sa fie perfect interfatabil cu Sistemul Electronic National (SEN)
  
• 
  Sistemul oferit trebuie sa fie perfect compatibil standardului 3Dsecure elaborat de Visa si MasterCard ( Verified by Visa si MasterCard Secure Code) precum si cu standardele celorlalte organizatii emitente de carduri ( American Express, JCB, Dinners si Discover).
  
• 
  Sistemul trebuie sa poata fi adaptat oricaror cereri sau noi standarde elaborate fie de organizatiile internationale emintenet de carduri, fie de alte autoritati romane.
  
• 
  Sistemul trebuie sa fie recunoscut de catre RomCard SA, portalul tehnic de autorizare pentru Romania.
  
• 
  Sistemul trebuie sa fie auditat PCI-DSS ( Payment Card Industry- Data Security Standard) sau echivalent, conform normelor internationale.
  
• 
  Sistemul sa se poate interfata cu orice aplicatie de tip sistem acceptare plati online in tehnologiile : PHP, ASP-VB, ASP-JS, Java Scripting, Perl, ColdFusion si DotNet
  
• 
  Sistemul trebuie sa fie securizat utilizind certificate digitale de tip SSL si sa aiba posibilitatea de a transmite si primi mesaje criptate dupa protocoalele : H-Mac si RSA_Sha1.
  
• 
  Ofertantul trebuie sa ofere module predefinite, care se pot adapta functie de cerintele speciale ale beneficiarilor, pentru urmatoarele tehnologii si limbaje : PHP, ASP-VB, ASP-JS, Java Scripting, Perl, ColdFusion si DotNet. Aceste module (API) sunt livrate in mod gratuit beneficiarilor impreuna cu instructiunile de implementare.
  

4.3.7Componenta “Arhivare continut si gestiune a inregistrarilor electronice”

Informatiile publicate la nivel de portal vor fi supuse unui proces riguros de arhivare continut si gestiune a inregistrarilor format electronic.

Pe baza nomenclatoarelor arhivistice existente sau viitoare se vor constitui scheme de clasificare ce vor reprezenta organizarea de baza a continutului in vederea implementarii procesului de arhivare la nivel institutional.
Componenta de arhivare continut si gestiune a inregistrarilor electronice trebuie sa se integreze cu portalul e-Romania in vederea asigurarii trecerii in mod unitar si controlat a informatiei din zona documentelor curente publicate in zona de arhiva istorica format electronic.

4.3.7.1Dictionar de termeni

• 
  Schema de clasificare: organizarea informatiilor supuse procesului de arhivare avand la baza un nomenclator arhivistic;
  
• 
  Folder: dosar format electronic ce contine documente;
  
• 
  Inregistrare: document format electronic;
  
• 
  Clasa: structura din cadrul schemei de clasificare ce contine foldere;
  
• 
  Retentie: pastrarea documentelor in cadrul unei scheme de clasificare;
  
• 
  Dispozitie: finalitatea operatiei de retentie ce consta in luarea unei decizii cu privire la informatiile aflate dub retentie;
  
• 
  Clasificare: operatia de catalogare a unei clase, folder sau inregistrari pe baza schemei de clasificare;
  
• 
  Distrugere: actiune in cadrul fazei de dispozitie, operatie de distrugere efectiva a informatiilor din cadrul schemei de clasificare;
  

4.3.7.2Cerinte generale

• 
  Componenta trebuie sa fie furnizata sub forma unui set integrat de aplicatii software functionand in regim client-server, cu o interfata de tip web-based, accesibila prin intermediul unui browser web;
  
• 
  Ca sistem de gestiune a bazei de date, componenta trebuie sa poata folosi oricare din urmatoarele: Oracle Database, Microsoft SQL Server, IBM DB2 Universal Database;
  
• 
  Ca sistem de operare server, componenta nu trebuie sa limiteze alegerea acestuia, ea trebuind sa poata opera cu aceleasi functiuni pe oricare din urmatoarele variante de sisteme de operare: Microsoft Windows (2000 sau 2003), variante de Linux (ex. RedHat), variante de Unix (ex. Solaris, HP-UX, IBM AIX) si Mac-OS X;
  
• 
  Ca server de aplicatii, componenta nu trebuie sa limiteze alegerea acestuia, ea trebuind sa poata opera cu aceleasi functiuni pe oricare din urmatoarele variante de servere de aplicatii: Apache Tomcat, BEA Weblogic, IBM WebSphere Application Server, JBoss Application Server, Oracle Application Server;
  
• 
  Componenta trebuie sa asigure compatibilitate pentru interfata de tip web-based pentru cel putin urmatoarele browsere web: Internet Explorer, Mozilla Firefox, Netscape, Safari;
  
• 
  Componenta trebuie sa asigure suport pentru tehnologia J2EE, XML si suport pentru servicii web de tip SOAP - Java si .NET;
  
• 
  Componenta trebuie sa fie compatibila cu standardele IPv4 si IPv6;
  
• 
  Componenta trebuie sa poata oferi capabilitati de migrare si stocare a continutului catre diferite medii externe de stocare precum: NetApp, Hitachi, EMC, IBM;
  
• 
  Componenta trebuie sa integreze continutul si serviciile de tip arhiva documente precum si alte servicii externe intr-o arhitectura orientata pe servicii (tip SOA);
  
• 
  Componenta trebuie sa fie deschisa la integrarea cu alte solutii informatice si sa ofere posibilitatea accesului la toate functiile sale direct dintr-un limbaj de programare. Limbajele de programare suportate trebuie sa includa: Visual Basic, Java, C Sharp (C#);
  
• 
  Toate functiile componentei, apelabile din aceste limbaje, trebuie sa fie complet documentate si disponibile printr-un SDK (eng. “Software Development Kit”). Platforma trebuie sa includa o suita extinsa de functii API (eng. “Application Programming Interface”) bazate pe tehnologiile .NET Framework si J2EE;
  
• 
  Interfata de utilizare a platformei trebuie sa fie unitara, sa expuna interfete de tip Web, similare cu mecanismele obisnuite de lucru cu documente si sa fie disponibila in limba romana;
  
• 
  Administrarea platformei trebuie sa se efectueze prin intermediul unei interfete unitare de tip Web si sa fie disponibila in limba romana. Platforma trebuie sa puna la dispozitie un singur punct de acces pentru gestiunea si administrarea tuturor depozitelor de documente, a serverelor, a utilizatorilor si grupurilor, indiferent de locatia lor;
  
• 
  Interfetele de lucru oferite de catre platforma trebuie sa permita selectii multiple de moduri de lucru astfel incat sa asigure atat accesul complet la toate functionalitatile puse la dispozitie precum si accesul restrans la functionalitati. Metoda de selectie a modului de lucru trebuie sa fie disponibila fiecarui utilizator al platformei;
  
• 
  Componenta trebuie sa asigure integrarea cu LDAP pentru autentificarea si managementul centralizat al utilizatorilor. Platforma trebuie sa se integreze cel putin cu Microsoft Active Directory;
  
• 
  Componenta trebuie sa asigure, in mod alternativ, mecanisme interne de autentificare, definire si gestionare a utilizatorilor. Deasemenea, componenta trebuie sa ofere, in mod alternativ, mecanisme de autentificare si gestionare a utilizatorilor definiti la nivelul sistemului de operare server;
  
• 
  Componenta trebuie sa ofere posibilitatea de a autentifica utilizatorii folosind credentiale standard si metode de autentificare folosind framework-uri de autentificare si mecanisme de tip Single Sign-On;
  
• 
  Componenta trebuie sa ofere un model intern de date la nivelul bazei de date, organizat pe tabele la nivel de tip de document arhivat (cel putin o tabela pe tip de document arhivat), astfel incat sa se obtina indici ridicati de performanta la nivelul bazei de date in momentul utilizarii unui anumit tip de document in operatii ce implica volume mari de informatie sau un numar foarte mare de atribute;
  
• 
  Componenta trebuie sa ofere nativ posibilitatea interfatarii cu surse externe de informatie precum SGBD-uri, aplicatii externe, fara a fi nevoie de dezvoltari suplimentare de cod. Configurarea accesului la surse externe de informatie trebuie sa fie accesibila doar administratorilor;
  
• 
  Componenta trebuie sa asigure stocarea fisierelor in sisteme de fisiere si metadatele in baze de date standard;
  
• 
  Componenta trebuie sa suporte depozite de documente distribuite, sa ofere posibilitatea de a fi configurat astfel incat accesul utilizatorilor la aceste depozite sa fie transparent si intuitiv din punct de vedere al navigatiei.
  

4.3.7.3Cerinte functionale

• 
  Componenta trebuie sa ofere un mecanism pentru a crea pachete cu toate dezvoltarile sau modificarile solutiei in vederea migrarea tuturor schimbarilor din mediile de dezvoltare si testare in mediul de productie. Acest mecanism trebuie sa construiasca un pachet cu toate tipurile de documente nou create, permisiuni asociate, reguli de procesare si toate celelalte schimbari care trebuie facute pe platforma de productie pentru a suporta schimbarea;
  
• 
  Componenta trebuie sa ofere suport pentru importul in aplicatie a unui fisieri sau a mai multor fisiere prin folosirea de metode de tip “Drag and Drop”;
  
• 
  Componenta trebuie sa ofere suport la stocare pentru orice format de fisier;
  
• 
  Componenta trebuie sa permita aplicarea si generarea de politici de securitate, conform unor sabloane predefinite, ce pot include atat utilizatori cat si grupuri de utilizatori;
  
• 
  Componenta trebuie sa asigure preluarea automata a permisiunilor de securitate in momentul in care se vor adauga noi documente sau noi elemente de structura tip folder in cadrul depozitului de documente;
  
• 
  Componenta trebuie sa ofere utilizatorilor posibilitatea de a defini drepturi de acces la nivel de obiect in orice moment. Utilizatorii vor putea sa acorde drepturi altor utilizatori sau grupuri de utilizatori. Trebuie sa fie posibil sa se gestioneze nivelurile de acces la utilizatori individuali si la grupuri de utilizatori;
  
• 
  Securitatea trebuie sa poata fi definita la fiecare din nivelurile: director, subdirector, document sau componente ale documentelor;
  
• 
  Pentru fiecare document gestionat, componenta trebuie sa permita stocarea mai multor tipuri de reprezentari electronice, acest lucru fiind transparent pentru utilizator. De exemplu, daca pentru un document sunt stocate reprezentarea Microsoft Word precum si cea Adobe PDF, atunci la regasire componenta va prezenta un singur document, dar utilizatorul va putea sa afiseze lista reprezentarilor disponibile si sa o selecteze pe cea dorita. Implicit, fiecare utilizator va trebui sa-si poata defini preferinta pentru o anumita reprezentare iar componenta sa o foloseasca pe aceasta (daca exista) atunci cand va prezenta continutul unui document catre utilizator;
  
• 
  Componenta trebuie sa ofere o structura ierarhica standard a directoarelor si sub-directoarelor (asemanator cu Windows) pentru a permite utilizatorilor si grupurilor de utilizatori sa-si gestioneze si sa-si organizeze arhiva de documente;
  
• 
  Componenta trebuie sa ofere administratorilor capacitatea de a defini si de a programa job-uri automatizate de administrare pentru monitorizarea si mentenanta platformei, fara a fi nevoie scrierea suplimentara de cod;
  
• 
  Componenta trebuie sa ofere administratorilor capacitatea de a executa aplicatii externe (executabil sau modul Java) in cadrul unui job de administrare automatizat, fara a fi nevoie de scriere suplimentara de cod;
  
• 
  Componenta trebuie sa suporte reprezentarea unei scheme de clasificare business, prin care folderele format electronic sunt plasate intr-o structura organizata si consistenta cu natura schemei de clasificare;
  
• 
  Componenta trebuie sa fie capabil sa suporte scheme de clasificare business ierarhice, cu minim trei nivele sub nivelul radacina; solutia trebuie sa suporte niveluri variate ca arborescenta la diferite puncte din cadrul schemei de clasificare;
  
• 
  Componenta trebuie sa permita unui utilizator autorizat adaugarea de noi clase la schema de clasificare business, fara a afecta clasele si folderele format electronic organizate conform cu schema de clasificare;
  
• 
  Componenta nu trebuie sa impuna la nivel de arhitectura sau design, limitari legate de numarul de clase ce poate fi creat in orice punct din cadrul schemei de clasificare;
  
• 
  Componenta trebuie sa permita unui utilizator autorizat sa dezactiveze clase si totodata sa previna adaugarea ulterioara de foldere la aceasta clasa sau descendentii acesteia;
  
• 
  Componenta trebuie sa permita unui utilizator autorizat stergerea unei clase goale, fara continut sau descendenti, dar sa previna stergerea unei clase care are constinut sau descendenti;
  
• 
  Componenta trebuie sa suporte scheme multiple de clasificare business;
  
• 
  Componenta trebuie sa suporte scheme distribuite de clasificare business ce pot fi mentinute si getionate in cadrul unei retele de calculatoare;
  
• 
  Componenta trebuie sa suporte utilizarea de atribute la nivel de clasa si trebuie sa restrictioneze abilitatea unui utilizator autorizat de a adauga sau modifica atribute la nivel de clasa;
  
• 
  Componenta trebuie sa suporte captura timestamp-ului de creare sau modificare in vederea executarii;
  
• 
  Componenta trebuie sa ofere cel putin doua tehnici de denumire a claselor, tehnici ce vor fi folosite si la numirea folderelor format electronic ce vor fi organizate in cadrul schemei de clasificare:
  

• 
  tehnica de alocare a unei etichete simple astfel incat acumularea etichetelor in urma unei parcurgeri ierarhice in cadrul schemei sa permita construirea numelui complet al clasei;
  
• 
  tehnica de alocare a unei referinte controlate in format numeric sau alfanumeric pentru fiecare clasa astfel incat acumularea referintelor in urma unei parcurgeri ierarhice in cadrul schemei de clasificare sa permita construirea referintei complete a acelei clase;
  

Exemplu:

“Departament Financiar>Contabilitate” este echivalent cu referinta “2.1”

“Departament Financiar>Contabilitate>Birou plati” este echivalent cu referinta “2.1.1”

• 
  Componenta trebuie sa permita aplicarea simultana a tehnicilor de denumire a claselor sau separat, in acelasi timp;
  
• 
  Componenta trebuie sa permita definirea de sabloane de denumire in cadrul tehnicilor de alocare de denumire; sabloanele trebuia sa poata fi controlate doar de catre utilizatori autorizati;
  

Exemplu:

[A-Z]+'_''P'[0-9][0-9][0-9] pentru FIN_P123

• 
  Componenta trebuie permita repetarea, la nivele diferita in cadrul organizarii ierarhice a schemei de clasificare, a unei denumiri de clasa ce reprezinta doar o parte componenta din aceasta;
  

Exemplu:

“Departament Financiar>Contabilitate>Birou plati” cu repetare a componentei “Birou plati” in alt punct din cadrul schemei de clasificare:

“Departament Tehnic>Birou plati”

• 
  Componenta trebuie sa asigure unicitatea la nivelul unei scheme de clasificare a denumirii complete a unei clase; denumirea completa reprezinta acumularea denumirilor de clase in urma pargurgerii ierarhice in cadrul schemei
  

Exemplu:

Denumirea completa a clasei “Birou plati” este “Departament Financiar>Contabilitate>Birou plati”

• 
  Componenta trebuie sa suporte mostenirea de atribute la nivelurile inferior ierarhice din cadrul unei scheme de clasificare astfel incat, in mod implicit, adaugarea unei noi clase (clasa copil) va consta in includerea automata a atributelor definite la nivelul clasei de rang superior (clasa parinte);
  
• 
  Componenta trebuie sa ofere posibilitatea modificarea, suprascrierea atributelor mostenite la nivel individual de clasa;
  
• 
  Componenta trebuie sa permita adaugarea de foldere doar la nivelurile cele mai de jos din punct de vedere ierarhic al oricarui punct din schema de clasificare business;
  
• 
  Numarul de foldere care poate fi creat sub o anumita clasa din cadrul schemei de clasificare sau creat la modul general la nivel de componenta, trebuie sa fie infinit;
  
• 
  Componenta trebuie sa ofere posibilitatea utilizarii de atribute pentru foldere in aceeasi masura cu inregistrarile;
  
• 
  Componenta trebuie sa permita unui utilizator autorizat posibilitatea de a modifica metoda de calcul a duratei de retentie pentru foldere;
  
• 
  Componenta trebuie sa permita controlul operatiei de creare foldere la nivel de clasa prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa ofere posibilitatea de a inhiba, temporar sau permanent, posibilitatea de a adauga inregistrari la un folder; Componenta trebuie sa asigure in acest timp accesul in mod regasire sau consultare la inregistrarile existente in acel folder;
  
• 
  Componenta trebuie sa restrictioneze pe baza de roluri sau profiluri utilizatori accesul la functia de inhibare adaugare inregistrari la un folder;
  
• 
  Componenta trebuie sa inregistreze automat data la care s-a realizat inhibarea adaugarii de inregistrari la un folder; Componenta trebuie sa poata utiliza aceasta data inregistrata in vederea calcularii duratei de retentie pentru acel folder;
  
• 
  Componenta trebuie sa permita unui utilizator autorizat sa elimine inhibarea adaugarii de inregistrari la un folder;
  
• 
  Componenta trebuie sa permita controlul structurii de organizare la nivel de folder, astfel incat, la un nivel inferior ierarhic, sa se permita adaugarea de inregistrari si nu de alte foldere;
  
• 
  Componenta trebuie sa previna distrugerea sau stergerea unui folder sau a oricarei inregistrari din acest folder sau metadate aferente acestora, cu exceptia urmatoarelor situatii:
  

• 
  distrugerea rezultata in urma aplicarii unei politici de retentie;
  
• 
  stergerea controlata, ca parte integrata din cadrul unui proces de audit;
  

• 
  Componenta trebuie sa permita unui utilizator autorizat reclasificarea unui folder, a unui grup de foldere sau inregistrari; Componenta trebuie sa jurnalizeze istoricul clasificarilor efectuate la nivel de folder sau inregistrare;
  
• 
  Componenta trebuie sa suporte crearea de legaturi relationale (link-uri) intre foldere ce sunt clasificare in puncte diferite din cadrul schemei de clasificare business;
  
• 
  Componenta trebuie sa permita gestiunea inregistrarilor ce sunt organizate in mai multe parti componente, in vederea:
  

• 
  capturarii si declararii de inregistrari in asa fel incat sa se pastreze relatiile intre partile componente;
  
• 
  retinerii integritarii structurale a inregistrarii;
  
• 
  suportarii ulterioare a gestiunii, consultarii, cautarii unei inregistrari ca o singura entitate;
  
• 
  dispozitia unei inregistrari ca o singura entitate, intr-o singura operatie;
  

• 
  Componenta trebuie sa previna modificarea continutului unei inregistrari declarate;
  
• 
  Componenta trebuie sa asigure faptul ca, in vederea completarii procesului de declarare, toate inregistrarile sunt asociate la cel putin un folder;
  
• 
  Componenta nu trebuie sa impuna, prin arhitectura sau design, limitari practice asupra numarului maxim de inregistrari ce pot fi capturate si declarate intr-un folder sau global la nivelul componentei;
  
• 
  Componenta trebuie sa permita unui utilizator autorizat relocarea unei inregistrari in alt folder;
  
• 
  Componenta trebuie sa permita definirea de tipuri distincte de inregistrari precum si gestiunea unitara sau separata a politicilor de retentie la nivel de inregistrare
  
• 
  Componenta trebuie sa ofere un tip de baza de inregistrare, astfel incat toti utilizatorii autorizati sa poata defini noi inregistrari plecand de la acest tip de baza;
  
• 
  Componenta trebuie sa permita controlul operatiei de creare de noi tipuri de inregistrari prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa permita definirea de atribute la nivel de tip inregistrare astfel incat, ulterior, in momentul aplicarii politicilor de retentie la nivel de inregistrare, componenta sa poata utiliza aceste atribute in vederea calcularii duratei de retentie;
  
• 
  Componenta trebuie sa permita utilizarea de atribute la nivel de inregistrari;
  
• 
  Componenta trebuie sa ofere utilizatorilor autorizati posibilitatea de adaugare de noi atribute ulterior etapei de definire a tipurilor de inregistrari; Componenta trebuie sa asigure integritatea inregistrarilor si a atributelor asociate in cazul adaugarii de noi atribute;
  
• 
  Componenta trebuie sa inregistreze automat timestamp-ul declararii unei inregistrari la nivel de element atribut in cadrul inregistrarii;
  
• 
  Componenta trebuie sa permita alocarea automata a unui identificator unic la nivel de componenta pentru fiecare inregistrare declarata; Componenta trebuie previna modificarea identificatorului unic alocat la nivel de inregistrare;
  
• 
  Componenta trebuie sa permita definirea si utilizarea de marcaje la nivel de inregistrare pentru a putea reprezenta informatii legate de locatia fizica din arhiva sau de nivelul de securitate aferent; Componenta trebuie sa trateze si sa reprezinte in mod diferit marcajele fata de atribute;
  
• 
  Componenta trebuie sa permita asocierea unui marcaj la una sau mai multe inregistrari;
  
• 
  Componenta trebuie sa jurnalizeze ca informatie auditabila toate modificarile valorilor atributelor la nivel de inregistrare;
  
• 
  Componenta trebuie sa ofere facilitati de cautare, regasire si vizualizare pentru clase, foldere, marcaje si inregistrari;
  
• 
  Componenta trebuie sa fie capabil sa caute dupa toate atributele aferente inregistrarilor;
  
• 
  Componenta trebuie sa fie capabil sa construiasca filtre de cautare prin combinarea termenilor si prin utilizarea in constructie de expresii logice;
  
• 
  Componenta trebuie sa ofere posibilitatea definirii si salvarii a criteriilor de cautare; Componenta trebuie sa ofere posibilitatea reutilizarii criteriilor de cautare salvate;
  
• 
  Componenta trebuie sa prezinte setul de rezultate ca o lista tabelara cu coloane sortabile; Componenta trebuie sa notifice utilizatorul in cazul in care setul rezultat nu contine informatii;
  
• 
  Componenta trebuie sa respecte schema de securitate aplicata la nivel de clase, foldere si inregistrari astfel incat in urma procesului de cautare si regasire, utilizatorii sa aiba acces doar la informatiile la care schema de securitate permite acest lucru;
  
• 
  Componenta trebuie sa suporte accesul concurent al utilizatorilor multipli la facilitile de cautare, regasire si vizualizare pentru clase, foldere, marcaje si inregistrari;
  
• 
  Componenta trebuie sa ofere un mecanism propriu pe baza de reguli pentru definirea si ulterior modificarea politicilor de retentie si dispozitie; Componenta trebuie sa permita alocarea politicilor de retentie si dispozitie la nivel de clase, foldere si inregistrari;
  
• 
  Componenta trebuie sa suporte un identificator unic pentru fiecare politica de retentie si dispozitie;
  
• 
  Componenta trebuie sa permita controlul operatiei de definire si modificare politici de retentie si dispozitie prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa suporte politici de dispozitie care sa poata contine:
  

• 
  perioada de retentie ce poate incepe la o anumita data sau la un anumit tip de eveniment
  
• 
  un tip de eveniment ce determina inceperea perioadei de retentie
  
• 
  un set de instructiuni de dispozitie ce trebuie aplicate la finalul perioadei de retentie
  

• 
  Componenta trebuie sa suporte perioade de retentie care pot fi exprimate ca:
  

• 
  numar de luni (de la 1 la 11);
  
• 
  numar de ani (de la 1 la 100);
  
• 
  combinatie de luni si ani;
  
• 
  retentie permanenta (fara limita de timp);
  

• 
  Componenta trebuie sa suporte urmatoarele tipuri de evenimente ce pot declansa automat inceputul perioadei de retentie:
  

• 
  data eliminarii inhibarii adaugarii de inregistrari la folder;
  
• 
  data inhibarii adaugarii de inregistrari la folder;
  
• 
  data declararii unei inregistrari intr-un folder;
  
• 
  data ultimei actiuni de aprobare a dispozitiei;
  

• 
  Componenta trebuie sa ofere posibilitatea alocarii unor politici de retentie predefinite la nivel de clase, foldere sau inregistrari; Componenta trebuie sa ofere reguli predefinite de calcul a duratei de retentie in cadrul politicilor de retentie puse la dispozitie;
  
• 
  Componenta trebuie sa permita, in mod implicit dar nu obligatoriu, ca alocarea unei politici de retentie la nivel de clasa sa fie mostenita la toate nivelurile inferior ierarhice din cadrul schemei de clasificare business;
  
• 
  Componenta trebuie sa previna eliminarea, la nivel de clasa, folder sau inregistrare, a unei politici de retentie mostenite de la un nivel superior ierarhic;
  
• 
  Componenta trebuie sa ofere un mecanism propriu de stabilire a precedentei unei politici de retentie fata de una sau mai multe politici de retentie aplicate la nivel de clasa, folder sau inregistrare;
  
• 
  Componenta trebuie sa permita controlul operatiei de aplicare sau eliminare de politici de retentie asupra unei clase, folder sau inregistrari prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa permita alocarea unei politici noi de retentie asupra unei clase, folder sau inregistrari care are deja aplicata una sau mai multe politici de retentie;
  
• 
  Componenta trebuie sa permita propagarea automata a modificarilor efectuate asupra unei politici de retentie mostenita ierarhic in cadrul unei scheme de clasificare;
  
• 
  Componenta trebuie sa ofere mecanisme proprii prin care un utilizator autorizat poate bloca temporar procesul de dispozitie aplicat asupra unei clase, folder sau inregistrari;
  
• 
  Componenta trebuie sa previna stergerea sau modificarea claselor, folderelor sau inregistrarilor care au fost blocate temporar in cadrul procesului de dispozitie aplicat asupra lor;
  
• 
  Componenta trebuie sa ofere rapoarte in legatura cu clasele, folderele si inregistrarile care sunt blocate temporar in cadrul procesului de dispozitie aplicat; Componenta trebuie sa permita utilizatorilor autorizati eliminarea blocarii temporare puse asupra claselor, folderelor si inregistrarilor;
  
• 
  Componenta trebuie sa mentina, in vederea auditarii, un jurnal cu istoricul politicilor de retentie aplicate la nivel de clasa, folder sau inregistrare;
  
• 
  Componenta trebuie sa determine automat inceputul si starea perioadei de retentie aplicate asupra claselor, folderelor si inregistrarilor care au alocate politici de retentie; componenta trebuie sa determine automat, pe baza perioadei de retentie, datele efective de dispozitie aferente claselor, folderelor si inregistrarilor;
  
• 
  Componenta trebuie sa ofere un mecanism propriu de dispozitie care, la cererea unui utilizator autorizat, va initia:
  

• 
  identificarea automata a tuturor claselor, folderelor si inregistrarilor care corespund criteriilor de dispozitie;
  
• 
  notificarea unui utilizator autorizat in legatura cu clasele, folderele si inregistrarile care s-au calificat conform criteriilor de dispozitie;
  
• 
  activarea alocarii, de catre un utilizator autorizat, a unei alte politici de retentie in vederea calificarii conform altor criterii de dispozitie;
  
• 
  executia actiunii de dispozitie, in urma confirmarii utilizatorului autorizat;
  

• 
  Componenta trebuie sa asigure ca toate actiunile necesare unei politici de dispozitie sunt aplicate tuturor inregistrarilor dintr-un folder sau tuturor folderelor dintr-o clasa, ca un intreg, exceptie cazul in care exista o politica de dispozitie suplimentara alocata pentru una sau mai multe inregistrari sau foldere;
  
• 
  Componenta trebuie sa ofere interfata de confirmare din partea utilizatorilor autorizati pentru toate actiunile aferente unei politici de dispozitie;
  
• 
  Componenta trebuie sa ofere interfata de dubla confirmare din partea utilizatorilor autorizati pentru toate actiunile ireversibile aferente unei politici de dispozitie;
  
• 
  Componenta trebuie sa controleze accesul la actiunile aferente politicilor de dispozitie prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa asigure ca, in conditii normale de operare, evenimentele din cadrul unei politici de dispozitie ce au ca factor de declansare data sistemului nu sunt afectate de modificarea artificiala a datei curente din interiorul mecanismelor proprii de calcul a perioadei de retentie;
  
• 
  Componenta trebuie sa ofere mecanisme proprii ce, in cazul modificarilor valorilor atributelor ce declanseaza evenimente la nivel de politica de retentie, reinitiaza automat calculul perioadei de retentie in functie de metoda de calcul curenta; componeta trebuie sa mentina, in vederea auditarii, un jurnal cu toate modificarile efectuate asupra valorilor acestor atribute;
  
• 
  Componenta trebuie sa ofere capabilitati de identificare a claselor, folderelor si inregistrarilor care au blocat temporar procesul de dispozitie, si deasemenea sa nu execute nici o actiune aferenta procesului de dispozitie atat timp cat blocajul este activ;
  
• 
  Componenta trebuie sa ofere un mecanism propriu ce permite consultarea utilizatorilor autorizati in vederea aprobarii unor dispozitiei sau aprobarii distrugerii inregistrarilor; mecanismul trebuie sa poata permita cel putin:
  

• 
  amanarea procesului de aprobare, rezultand in prelungirea automata perioadei de retentie;
  
• 
  stabilirea inregistrarilor care vor fi pastrate permanent, imediat sau dupa finalizarea perioadei de retentie;
  
• 
  distrugerea inregistrarilor, imediat sau dupa finalizarea perioadei de retentie;
  

• 
  Componenta trebuie sa ofere acces utilizatorilor autorizati la atributele aferente inregistrarilor supuse procesului de aprobare;
  
• 
  Componenta trebuie sa permita distrugerea imediata a inregistrarilor in cadrul derularii unei politici de dispozitie aplicate si care are definita aceasta actiune, doar prin realocarea unei noi politici de dispozitie ce autorizeaza in mod explicit aceasta actiune;
  
• 
  Componenta trebuie sa permita, in cadrul proceselor iterative de aprobare a dispozitiei, adaugarea progresiva de informatii ce reflecta motivatia deciziei si actiunea intreprinsa; aceste informatii vor trebuie constituite sub forma unui jurnal ce poate fi consultat pana si dupa distrugerea inregistrarilor;
  
• 
  Componenta trebuie sa inregistreze automat data ultimei actiuni din cadrul unui proces de aprobare a dispozitiei si sa permita utilizarea acestei date ca factor de declansare a evenimentelor definite in cadul politicilor de retentie;
  
• 
  Componenta trebuie sa asigure utilizatorilor autorizati interfata de confirmare a actiunii de distrugere, ca pas obligatoriu din politica de dispozitie si pozitionat inaintea oricarei actiuni ce poate fi intreprinsa asupra claselor, folderelor sau inregistrarilor;
  
• 
  Componenta trebuie sa ofere utilizatorilor autorizati posibilitatea de a renunta la operatia de distrugere in cazul in care nu se ofera confirmarea explicita a acestei actiuni;
  
• 
  Componenta trebuie sa permita controlul functiilor de stergere ad-hoc de clase, foldere sau inregistrari in afara politicilor de dispozitie aplicate prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa diferentieze si sa trateze in mod distinct functiile de stergere ad-hoc de clase, foldere sau inregistrari si functia de distrugere din cadrul politicii de dispozitie; componenta trebuie sa permita alocarea diferita de permisiuni asupra functiilor de stergere si distrugere prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa ofere, pentru folderele sau inregistrarile stocate pe medii reinscriptibile, functii de stergere completa a acestora astfel incat restaurarea acestora sa nu poata fi efectuata prin functii aferente sistemului de operare sau prin intermediul unor procese specifice de recuperare a datelor;
  
• 
  Componenta trebuie sa ofere mecanisme proprii de acces si securizare a folderelor si inregistrarilor astfel incat sa nu fie permis accesul direct la acestea prin intermediul altor aplicatii sau a sistemului de fisiere de la nivelul sistemului de operare;
  
• 
  Componenta trebuie sa fie capabila sa pastreze un set minim de informatii asociate cu folderele sau inregistrarile distruse;
  
• 
  Componenta trebuie sa fie capabila sa pastreze un set minim de informatii asociate cu folderele sau inregistrarile distruse, in cazul in care actiunea de distrugere este initiata la un nivel superior ierarhic in cadrul schemei de clasificare;
  
• 
  Componenta trebuie sa ofere un set minim de informatii completabile de catre un utilizator autorizat in momentul executarii operatiei de stergere ad-hoc asupra folderelor sau inregistrarilor; componenta trebuie sa pastreze un jurnal cu aceste informatii in vederea consultarii ulterioare;
  
• 
  Componenta trebuie asigure distrugerea inregistrarilor care au mai multe versiuni, actiunea de distrugere trebuie sa trateze inregistrarea si versiunile acesteia ca un intreg;
  
• 
  Componenta trebuie sa ofere mecanisme proprii de autentificare precum si mecanisme de autentificare utilizand sisteme de gestiune a utilizatorilor de tip LDAP;
  
• 
  Componenta trebuie sa ofere mecanisme proprii de configurare a accesului de tip “Single Sign On”;
  
• 
  Componenta trebuie sa ofere utilizatorilor autorizati urmatoarele capabilitati de gestiune a utilizatorilor:
  

• 
  sa permita crearea de noi utilizatori;
  
• 
  sa permita sincronizarea utilizatorilor cu sisteme de gestiune a utilizatorilor de tip LDAP;
  
• 
  sa ofere posibilitatea inactivarii utilizatorilor in vederea blocarii accesului;
  
• 
  sa ofere posibilitatea stergerii utilizatorilor definiti;
  

• 
  Componenta trebuie sa permita definirea de politici de securitate globale pe intreaga schema de clasificare precum si la nivel de sectiune de schema de clasificare;
  
• 
  Componenta trebuie sa ofere, suplimentar fata de politicile de securitate, capabilitati de definire marcaje de tip “Public”, “Secret”, “Strict Secret” in vederea controlarii accesului utilizatorilor autorizati asupra folderelor si inregistrarilor declarate;
  
• 
  Componenta trebuie sa ofere marcaje cu cel putin cinci niveluri de acces, incepand de la cel mai permisiv nivel de acces si pana la cel mai restrictiv;
  
• 
  Componenta trebuie sa permita asocierea atat utilizatorilor cat si grupurilor la nivel de marcaj;
  
• 
  Componenta trebuie sa permita controlul operatiei de definire a marcajelor prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa permita controlul operatiei de aplicare a marcajelor la nivel de foldere sau inregistrari prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa previna definirea politicilor de securitate la nivel de foldere sau inregistrari utilizatorilor care nu sunt asociati rolurilor sau profilurilor ce permit astfel de operatii;
  
• 
  Componenta trebuie so ofere capabilitati de audit care sa permita jurnalizarea cel putin a urmatoarelor evenimente:
  

• 
  actiunea intreprinsa;
  
• 
  folderele si inregistrarile asupra carora s-a intreprins o actiune;
  
• 
  utilizatorul autorizat care a intreprins actiunea;
  
• 
  momentul producerii actiunii (timestamp);
  

• 
  Componenta trebuie sa fie capabila sa jurnalizeze in scopuri de audit a tuturor modificarilor efectuate la nivel de atribute foldere sau inregistrari;
  
• 
  Componenta trebuie sa asigure integritatea informatiilor de audit astfel incat acestea sa nu poata fi modificate in niciun fel, inclusiv de utilizatori autorizati cu rol de administrator;
  
• 
  Componenta trebuie sa ofere rapoarte ad-hoc care sa cuprinda informatii referitoare la:
  

• 
  actiuni intreprinse de un utilizator, grup de utilizatori intr-un interval definit de timp;
  
• 
  actiuni intreprinse asupra unui folder sau grup de foldere de catre un utilizator, grup de utilizatori intr-un interval definit de timp;
  
• 
  actiuni intreprinse asupra unui inregistrare sau grup de inregistrari de catre un utilizator, grup de utilizatori intr-un interval definit de timp;
  

• 
  Componenta trebuie sa ofere instrumente de baza de raportare in vedere monitorizarii activitatii de captura, declarare si gestiune a inregistrarilor;
  
• 
  Componenta trebuie sa permita stocarea rapoartelor in vederea executarii ulterioare prin specificarea parametrilor de executie definit in faza de constructie a rapoartelor;
  
• 
  Componenta trebuie sa ofere rapoarte predefinite ce vor evidentia situatia claselor, folderelor si inregistrarilor in cadrul schemei de clasificare business - la nivel global sau doar pentru o sectiune din schema de clasificare; rapoartele trebuie sa cuprinda cel putin urmatoarele informatii:
  

• 
  politica de securitate aplicata;
  
• 
  politica de retentie aplicata;
  
• 
  informatiile legate de clasificare (denumire, referinta);
  

• 
  Componenta trebuie sa permita controlul accesului la rapoarte si a executiei acestora prin utilizarea de roluri sau profiluri de utilizator;
  
• 
  Componenta trebuie sa permita afisarea si/sau tiparirea rapoartelor rulate;
  
• 
  Componenta trebuie sa ofere un set minim de rapoarte specifice procesului de gestiune a inregistrarilor; rapoartele trebuie sa ofere:
  

• 
  informatii volumetrice legate de folderele si inregistrarile care au aplicate politici de retentie;
  
• 
  lista folderelor si inregistrarilor care au aplicate politici de retentie;
  
• 
  lista politicilor de retentie definite;
  
• 
  lista folderelor si inregistrarilor care necesita aprobare in vederea distrugerii;
  
• 
  lista folderelor si inregistrarilor care au fost distruse sau care au fost excluse din procesul de distrugere;
  

• 
  Componenta trebuie sa ofere un set minim de statistici predefinite ce vor suprinde:
  

• 
  numarul de foldere creat intr-o anumita perioada de timp;
  
• 
  numarul de inregistrari declarate de un utilizator sau grup de utilizatori intr-o anumita perioada de timp;
  
• 
  numarul de inregistrari distruse in urma aplicarii politicilor de retentie;