Specializarea : Informatică [627004]

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE ȘTIINȚE

Specializarea : Informatică

LUCRARE DE LICENȚĂ

Coordonator științific
Lect . univ. dr. Daniel HUNYADI Absolvent: [anonimizat]
2020

2 UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE ȘTIINȚE

Specializarea : Informatică

Sistemul informatic distribuit
pentru eviden ța pacien ților în
sistemul asigur ărilor de
sănătate

Coordonator științific
Lect . univ. dr. Daniel HUNYADI Absolvent: [anonimizat]
2020

3 Declarație pentru conformitate asupra originalității operei
științifice
VIZAT
Conducător științific

Subsemnatul AGÎRBICEANU RAUL MARIUS domiciliat în localitatea Mediaș adresa poștală,
strada Visraru, nr.9, bl.102, ap.2, având actul de identitate seria SB nr. 746997, codul numeric
personal [anonimizat] înscris pentru susținerea lucrării de licență cu titlul, Sistemul
informatic distribuit pentru evidența pacienților în sistemul asigurărilor de sănătate ,

declar următoarele:
● opera șt iințifică nu aparține altei persoane, instituții, entități cu care mă aflu în relații de
muncă sau altă natură;
● opera științifică nu este contrară ordinii publice sau bunelor moravuri, iar prin aplicarea
acesteia nu devine dăunătoare sănătății ori vieții persoanelor, animalelor sau plantelor;
● opera științifică nu a mai fost publicată de subsemnatul / subsemnata sau de o terță
persoană fizică sau juridică, în țară sau în străinătate, anterior datei depunerii acesteia
spre evaluare în scopul obținerii recuno așterii științifice în domeniu.
Specific explicit că ideile prezentate sunt originale, iar sursele de informații care stau la
baza emiterii unor teorii originale au fost corect citate și prezentate în opera științifică.
Data: 19.06.2020
Numele și prenumele : Agîrbiceanu Raul Marius
Semnătura:
Notă: Prezenta declarație va purta viza conducătorului științific.

Cod. PO – ULBS – DPPI – 06_ed – 1_rev – 0 / 05.11
Copyright ©: http://ppi.ulbsibiu.ro/ro/despre/proceduri.php

4 Cuprin s

Introducere ………………………….. ………………………….. ………………………….. ………………………….. …… 6
Capitolul 1. Sistemul informatic pentru evidența pacienților în sistemul asigurărilor de sănătate
din România ………………………….. ………………………….. ………………………….. ………………………….. …. 7
1.1. Descrierea Platformei Informatice a Asigurărilor de Sănătate din România ………………. 7
1.1.1. Nivelul de bază ………………………….. ………………………….. ………………………….. ………. 7
1.1.2. Nivel ul central ………………………….. ………………………….. ………………………….. ……….. 8
1.2. Descrierea interfețelor SIUI ………………………….. ………………………….. ………………………… 9
1.2.1. Interfețele cu furnizorii de servicii medicale și farmaceutice ………………………….. … 9
1.2.2. Interfețele cu alte instituții ………………………….. ………………………….. ………………….. 11
1.3. Asigurarea securității informației ………………………….. ………………………….. ………………. 11
1.3.1. Autentificarea și autorizarea prin certificate digitale ………………………….. ………….. 13
1.3.2. Semnătura digitală ………………………….. ………………………….. ………………………….. … 15
Capitolul 2. Managementul Bazelor de Date ………………………….. ………………………….. ……………. 17
2.1. Sistem de gestionare a bazelor de date (DBMS) ………………………….. ………………………. 17
2.1.1. Obiectivele DBMS ………………………….. ………………………….. ………………………….. .. 17
2.1.2. Funcțiile DBMS ………………………….. ………………………….. ………………………….. …… 18
2.1.3. Componente ale unui DBMS ………………………….. ………………………….. ……………… 19
2.2. Proiectarea bazei de date ………………………….. ………………………….. ………………………….. 19
2.2.1. Obiectivele proiectarii bazelor de date ………………………….. ………………………….. …. 20
2.2.2. Vizualizare logică și fizică a bazei de date ………………………….. ……………………….. 20
2.2.3. Arhitectura sistemelor bazelor de date ………………………….. ………………………….. …. 21
2.2.4. Structuri de stocare: ………………………….. ………………………….. ………………………….. . 24
2.2.5. Faze în proiectarea bazelor de date ………………………….. ………………………….. ……… 24
Capitolul 3. Prezentare Android ………………………….. ………………………….. ………………………….. …. 28
3.1. Arhitectura sistemului de operare android ………………………….. ………………………….. …… 28
3.2. Permisiunile de sistem ………………………….. ………………………….. ………………………….. …. 30

5 3.3. Gestionarea credențialelor ………………………….. ………………………….. ………………………… 34
3.4. Criptarea ………………………….. ………………………….. ………………………….. ……………………. 35
3.5. Malware și pr obleme de securitate ………………………….. ………………………….. …………….. 35
3.6. Reverse engineering ………………………….. ………………………….. ………………………….. ……. 37
3.7. Atenuarea riscurilor ………………………….. ………………………….. ………………………….. …….. 37
Capitolul 4. Aplica ție Android pentru eviden ța pacien ților în sistemul asigur ărilor de s ănătate .. 39
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ……. 55
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …. 56

6 Introducere
Sistemul Informatic Unic Integrat (SIUI) al Asigurărilor de Sănătate este utilizat de Casa
Națională de Asigurări de Sănătate (CNAS) și de Casele de Asigurări de Sănătate (CAS) din
teritoriu pentru îndeplinirea funcțiilor specifice de gestionare a cheltuirii bugetului asigurărilor
de sănătate. Acest sistem este extins prin adăugarea funcționalităților specifice Prescripției
Electronice, o modalitate de evidență inf ormatizată și de automatizare a prescrierii și
eliberării medicamentelor compensate și gratuite.
SIUI+PE este proiectat utilizând o arhitectură centralizată. Colectarea și prelucrarea
datelor se realizează prin intermediul unei ferme de ser vere de aplicație ce accesează datele
stocate în baza de date centrală, prezentând seturi diferite de funcționalități pentru diferite
categorii de utilizatori, și anume:
• Funcționalități specifice Casei Naționale de Asigurări de Sănătate (CNAS);
• Funcțional ități specifice Caselor de Asigurări de Sănătate (CAS):
o 41 de Case de Asigurări de Sănătate Județene
o Casa de Asigurări de Sănătate a Municipiului București
o Casa Asigurărilor de Sănătate a Apărării, Ordinii Publice, Siguranței
o Naționale și Autorității Judec ătorești (CASAOPSNAJ)
o Casa Asigurărilor de Sănătate a Ministerului Transporturilor,
Construcțiilor și Turismului (CASMTCT)
• Funcționalități specifice Sistemul Informatic de Prescripție Electronică (PE);
• Funcționalități specifice furnizorilor de servicii medico -farmaceutice.
La nivelul CNAS se pot accesa toate datele din baza de date centralizată: atât datele
proprii, cât și ce le de la CAS -uri. La nivelul CAS nu sunt accesibile toate datele din baza de date
centralizată, acestea sunt prefiltrate, astfel încât sa fie vizibile doar datele proprii.
La baza sistemului se află furnizorii de servicii medicale și farmaceutice, care col ectează
și prelucrează informațiile medicale primare specifice asiguratului, cât și informațiile cu
caracter administrativ care vor sta la baza decontării serviciilor prestate de furnizorii de
servicii medicale și Casele Județene de Asigurări de Sănătate.
Pentru furnizorii de servicii medico -farmaceutice sistemul prevede posibilitatea de acces
securizat online la aplicațiile prevăzute, prin intermediul internetului, acest document prezentând
detalii tehnice cu privire la modul de acces al acestor funcționalități.

7 Capitolul 1. Sistemul informatic pentru evidența pacienților în
sistemul asigurărilor de sănătate din România
1.1. Descrierea Platformei Informatice a Asigurărilor de Sănătate din
România
“Sistemul Informatic Unic Integrat (SIUI) al Asigurări lor de Sănătate este utilizat de
Casa Națională de Asigurări de Sănătate (CNAS) și de Casele de Asigurări de Sănătate (CA S)
din teritoriu pentru îndeplinirea funcțiilor specifice de gestionare a cheltuirii bugetului
asigurărilor de sănătate. Acest sistem e ste extins prin adăugarea funcționalităților specifice
Prescripției Electronice, o modalitate de evidență informatizată și de automatizare a prescrierii și
eliberării medicamentelor compensate și gratuite ”[27].
La nivelul CNAS se pot accesa toate datele di n baza de date centralizată: atât datele
proprii, cât și cele de la CAS -uri.
La nivelul CAȘ nu sunt accesibile toate datele din baza de date centralizată, acestea sunt
prefiltrate, astfel încât să fie vizibile doar datele proprii.
La baza sistemului se afl ă furnizorii de servicii medicale și farmaceutice, care colectează
și prelucrează informațiile medicale primare specifice asiguratului, cât și informațiile cu caracter
administrativ care vor sta la baza decontării serviciilor prestate de furnizorii de serv icii medicale
și Casele Județene de Asigurări de Sănătate [27].
Pentru furnizorii de servicii medico -farmaceutice sistemul prevede posibilitatea de acces
securizat online la aplicațiile prevăzute, prin intermediul internetului, acest document prezentând
detalii tehnice cu privire la modul de acces al acestor funcționalități.
1.1.1. Nivelul de bază
La nivelul de bază se află diversele categorii de furnizori cu care sistemul (SIUI)
operează schimburi de date [27]:
• furnizorii de servicii medicale furnizorii de dispoz itive medicale
• furnizorii de medicamente și servicii farmaceutice
Pentru toate tipurile de furnizori există aplicații informatice prin care aceștia pot raporta
către nivelul central serviciile prestate sau produsele furnizate și pot prelua de la nivelul ce ntral
setul de informațiile necesare înregistrării datelor primare și efectuării raportărilor. Aceste
aplicații vor fi numite în continuare „Aplicații de raportare”.

8 Pentru nivelul de bază, “sistemul oferă interfețe programatice de colectare și validare a
datelor. Prin intermediul acestor interfețe se pun la dispoziția furnizorilor de servicii medicale și
farmaceutice toate informațiile necesare cum ar fi cataloagele de servicii și de medicamente, dar
și datele de contract relevante ale furnizorului precum tarife contractate sau medici angajați,
pentru a face posibilă înregistrarea și raportarea datelor către nivelul central ”[27].
“Prin intermediul acestor interfețe se creează mecanisme prin care datele despre serviciile
prestate de fiecare furnizor de servi cii medicale și farmaceutice se transferă, în format electronic
în SIUI. Transferul poate fi făcut online, prin comunicație electronică directă securizată, sau
offline, pe un suport de stocare mobil. De asemenea există posibilitatea interogării sistemului de
către furnizorii de servicii medicale și farmaceutice pentru a sincroniza datele din aplicația de
raportare cu rezultatele prelucrării acestor raportări la nivel CJAS, prin transmiterea erorilor
detectate către fiecare furnizor de servicii medicale și f armaceutice ”[27].
1.1.2. Nivelul central
Aplicația SIUI, deși are o bază de date centralizată oferă funcționalități diferite pentru
cele două niveluri ierarhice teritoriale ale CNAS, nivelul caselor județene (CJAS) și nivelul casei
naționale (CNAS). Prezentăm în continuare diferențierea acestor funcționalități în funcție de
nivelul ierarhic al utilizatorilor, pentru o mai bună înțelegere a modului de operare al sistemului.
Nivelul CJAS
La nivel CJAS se vor consolida toate informațiile de interes pentr u sistemul informatic
integrat de la nivel județean. Aceste informații pot proveni fie, pe un flux informațional
prestabilit, prin transfer de date în format electronic, de la nivelul de bază, fie se pot opera cu
ajutorul interfețelor puse la dispoziție de sistem. La acest nivel sunt implementate regulile de
prelucrare a datelor care intră în sistem, indiferent de modalitatea lor de proveniență [27].
De asemenea, acest nivel este “responsabil cu gestionarea comunicării cu partenerii de
sistem de la nivelul inferior, aceștia neavând acces direct la nivel CNAS. În concluzie,
majoritatea funcționalităților sistemului vor fi implementate la nivel județean, acesta fiind nivelul
în care informațiile sunt prelucrate, iar în urma prelucrării vor fi obținute datele d e ieșire din
sistem către nivelul inferior. Fiecare proces identificat la nivel CJAS are un corespondent la nivel
CNAS, sistemul consolidând la nivel CNAS toate informațiile de interes, prelucrate de la toate
CJAS – urile, stabilindu -se astfel un flux infor matic care propagă informațiile de la nivel CJAS la
nivel CNAS ”[27].

9 Fluxurile de date de acest nivel al sistemului informatic integrat sunt legate atât de datele
necesare activității specifice (gestiunea contribuabililor, gestiunea fondului asigurărilor sociale
de sănătate, gestiunea asiguraților și gestiunea furnizorilor de servicii medicale și farmaceutice)
cât și de datele necesare sistemului ERP.
Nivelul CNAS
Acest nivel are 2 mari categorii de funcționalități fiecare cu propriul flux de date.
Prima o constituie elaborarea normelor care guvernează sistemul. La acest nivel se
stabilesc criteriile de evaluare a furnizorilor de servicii medicale și farmaceutice, contractele
cadru conform cărora se vor presta și deconta serviciile medicale și farmaceutice precum și care
sunt aceste servicii. Toate aceste elemente constituie o parte din regulile de funcționare a
Sistemului Informatic Unic Integrat al Asigurărilor de Sănătate din România, și pot fi denumite
generic “cataloage” sau “nomenclatoare”. Aceste info rmații sunt transmise prin intermediul unui
flux informațional către nivelul CJAS care, la rândul său, prin intermediul altui flux
informațional va transmite datele de interes la nivelul furnizorilor de servicii medicale și
farmaceutice [27].
A doua categorie de funcționalități ale acestui nivel o constituie funcționalitățile de
prelucrare a informațiilor de la nivel național, fie în vederea validării informațiilor de la nivel
județean, fie în vederea prelucrării statistice a informațiilor din sistem. Fluxul informațional care
deservește aceste funcționalități pleacă de la nivel CJAS și se caracterizează prin transmiterea la
nivel CNAS a tuturor informațiilor de interes în vederea prelucrării lor centralizat, la nivel
național.
1.2. Descrierea interfețelor SIUI
Sistemul informatic integrat este prevăzut cu interfețe de comunicare cu exteriorul prin
care se face transfer de date în format electronic. Aceste interfețe se împart în 2 mari categorii
[27]:
• interfețe cu furnizorii de servicii medicale, și
• farmac eutice interfețe cu alte instituții.
1.2.1. Interfețele cu furnizorii de servicii medicale și farmaceutice
Pentru a rezolva problemele legate de transferul de informații, în format electronic, cu
furnizorii de servicii medicale și farmaceutice, dar și cu angajato rii, au fost dezvoltate interfețe
cu fiecare categorie de parteneri.

10 O primă funcționalitate este actualizarea informațiilor necesare la nivelul partenerilor,
pentru bună desfășurare a activității cu informații actuale din SIUI. Aceasta este o funcționalit ate
generală a acestor interfețe necesară tuturor categoriilor de parteneri. Informațiile care se
sincronizează sunt legate de contractele în vigoare dintre fiecare furnizor de servicii medicale și
farmaceutice și CJAS, de serviciile medicale și farmaceuti ce pe care fiecare furnizor le poate
presta, de cataloagele specifice fiecărei categorii și de alte nomenclatoare generale gestionate la
nivel CNAS (de exemplu, nomenclatoare de localități, de străzi, etc.) [27].
O altă funcționalitate este raportarea serv iciilor prestate de fiecare furnizor de servicii
medicale și farmaceutice. Este tot o funcționalitate generală, acesta fiind scopul principal al
interfețelor dintre SIUI și furnizorii de servicii medicale și farmaceutice.
“Pentru transmiterea rezultatului prelucrării și validării serviciilor raportate de furnizorii
de servicii medicale și farmaceutice în SIUI, înapoi către fiecare furnizor a stării de validare și a
eventualelor erori detectate, este definit o altă funcționalitate, de sincronizare a rezultat ului
prelucrărilor raportărilor. În acest mod fiecare furnizor de servicii medicale și farmaceutice este
informat despre serviciile care pot fi decontate și care nu pot fi decontate, creându -se astfel
premisele controlului de către furnizorii de servicii m edicale și farmaceutice a sumelor încasate
din fondul național al asigurărilor de sănătate ”[27].
Există și funcționalități specifice anumitor categorii de furnizori de servicii medicale și
farmaceutice cum ar fi medicii de familie care sunt obligați să rap orteze asigurații aflați pe listele
lor, mișcările acestora sau schimbarea categoriei de asigurat, sau furnizorilor de dispozitive
medicale care pot descărca din SIUI informații referitoare la deciziile de acordare aprobate la
CJAS.
Prin intermediul acesto r interfețe se pot transfera informații legate de rețetele prescrise de
medici și de biletele de trimitere eliberate de aceștia. Aceste informații pot fi coroborate cu
raportările farmaciilor despre rețetele eliberate sau cu raportările furnizorilor de ser vicii medicale
care prestează serviciile prevăzute în biletele de trimitere. Pentru farmacii este definită o interfață
specială pentru interogarea informațiilor referitoare la rețetele prescrise [27].
SIUI permite validarea online, înainte de raportarea fi nală, a eligibilității serviciilor
declarate de furnizori precum și a calității de asigurat a beneficiarului de servicii medicale sau
farmaceutice permițând astfel medicilor și farmaciștilor să lucreze cu date actualizate în timp real
la nivel național, re ducând astfel posibilitatea prestării de servicii care nu vor fi decontate
ulterior.

11 Conexiunea prin Internet la SIUI este posibilă doar în mod securizat folosind protocolul
HTTPS/SSL și un certificat digital calificat, utilizat la autentificarea și autori zarea accesului
online la sistem, precum și la semnătura electronică.

1.2.2. Interfețele cu alte instituții
“Prin aceste interfețe se transferă, conform unor protocoale de comunicație, datele
necesare sistemului informatic integrat pentru desfășurarea în bune condițiuni a activității. Un
astfel de protocol este încheiat cu Biroul de Evidență Informatizată a Persoanei în care sunt
stabilite datele ce vor fi transferate și structura acestor date. Cu acest partener de sistem se
schimbă informa ții despre persoanele fizice care pot deveni asigurați și despre persoanele
decedate. Un alt protocol este încheiat cu ANAF (Agenția Națională de Administrare Fiscală)
care permite obținerea datelor referitoare la plata contribuțiilor la FNUASS necesare pe ntru
validarea calității de asigurat a beneficiarilor serviciilor medicale ”[27].
SIUI beneficiază de protocoale de schimb de date și cu alte instituții din care enumerăm:
Primăriile – pentru asistații social sau pauperi, Ministerul Muncii și Protecției Soc iale – pentru
pensionari și șomeri, Inspectoratul de Stat pentru Handicapați – pentru persoanele cu handicap,
Ministerul de Finanțe – pentru indicatorii economici necesari fundamentării bugetului și pentru
evidența contribuabililor, Institutul Național de Statistică – pentru diverși indicatori statistici
[27].
1.3. Asigurarea securității informației
Pentru asigurarea securității informațiilor transferate între aplicațiile de raportare și SIUI
este folosită o soluție bazată pe o infrastructură cu chei publice ( PKI), care utilizează criptografia
asimetrică oferind cadrul și serviciile ce pun la dispoziția utilizatorului metode pentru a genera,
distribui, controla, contoriza și revocă certificate cu chei publice [27].
Într-un sens mai larg, se poate spune că PKI i ntegrează certificatele digitale, criptografia
cu cheie publica și noțiunea de autoritate de certificare într -o arhitectură de securitate a rețelei.
Pentru a stabili un vocabular comun, prezentăm în continuare câteva concepte cheie legate de
autentificare prin certificate digitale.
Infrastructură cu chei publice (PKI) – arhitectură, tehnicile, practicile și procedurile care
contribuie în mod colectiv la implementarea și funcționarea sistemelor criptografice cu chei
publice, bazate pe certificate; PKI constă în hardware și software, baze de date, resurse de rețea,
proceduri de securitate și obligații legale, legate împreună și care colaborează pentru a furniza și

12 implementa atât serviciile de certificare cât și alte servicii asociate infrastructurii (de ex. M arca
temporală) [27].
Cheia privată – este una dintre cheile asimetrice aparținând unui utilizator și folosită
numai de acel abonat. În cazul sistemelor cu chei asimetrice, o cheie privată descrie
transformarea de semnare. În cazul sistemului asimetric de criptare, o cheie privată descrie
transformarea de decriptare. Cheia privată este [27]:
1. cheia al cărei scop este decriptarea sau crearea de semnătură pentru uzul exclusiv al
proprietarului;
2. acea cheie din perechea de chei care este cunoscută numai propriet arului.
Cheia publică – este una dintre cheile perechii asimetrice ale unui utilizator, care este
disponibilă publicului. În cazul sistemelor de criptare asimetrică, cheia publică definește
transformarea de verificare a semnăturii. În cazul criptării asime trice, cheia publică definește
transformarea de criptare a mesajelor.
Jeton (token) – structura de date folosită pentru schimbul dintre entități și care conține
informații transformate prin tehnici criptografice. Jetonul este semnat de operatorul unei
Auto rități de Înregistrare și poate fi folosit pentru autentificarea deținătorului său în relația sa cu
Autoritatea de Certificare.
Lista de Certificate Revocate (CRL) – listă emisă periodic sau imediat, semnată
electronic de către o autoritate, permițând iden tificarea certificatelor care au fost revocate sau
suspendate înainte de expirarea perioadei de validitate. CRL conține numele emitentului său,
data publicării, data următoarei actualizări, numerele seriale ale certificatelor revocate sau
suspendate și dat ele și motivele revocării sau suspendării lor [27].
Semnătură electronică – transformarea criptografică a datelor pentru a permite atât
verificarea originii și integrității datelor de către destinatarul acestora cât și protejarea
expeditorului și a destina tarului împotriva falsificării de către primitor; semnăturile electronice
asimetrice pot fi generate de către o entitate prin folosirea unei chei private și a unui algoritm
asimetric, ex. RSA.
Validarea certificatelor de cheie publică – “verificarea stării unui certificat, care permite
stabilirea dacă certificatul este revocat sau nu. Această problemă poate fi rezolvată pe baza CRL –
ului sau printr -o cerere trimisă direct prin protocolul OCSP (Online Certificate Status Protocol).
Folosind acest protocol, apl icațiile nu trebuie să consulte o listă mare (și uneori neactualizata) de
certificate (CRL), ci doar să trimită o cerere către un serviciu bazat pe protocolul OCSP

13 (conform RFC -2560) pentru verificarea stării certificatului în cauză. OCSP are dezavantajul că
presupune un acces online la serviciul OCSP ”[27].
Beneficiile ce rezultă din adaptarea sistemului la modelul PKI sunt:
• întregul sistem prezintă o portabilitate ridicată, utilizatorul având acces sigur din
diverse locații la informațiile sale;
• utilizator ii sistemului vor beneficia de comunicații sigure și secrete cu ajutorul
capacităților de criptare;
• sistemul permite atât separarea operației de identificare și autentificare de operația
de autorizare, cât și faptul că actele în forma lor clasică (pe supor t de hârtie) pot fi
înlocuite cu documente în format electronic.
“Procesul de adaptare a unor aplicații existente și de integrare a acestora într -o
infrastructură cu chei publice nu reprezintă o operație banală. Aceasta presupune că aplicațiile
sau mediul în care rulează ele să poată: să manipuleze cheile și certificatele în mod sigur; să
accepte și să proceseze certificatele valide; să fie capabile să obțină date relevante pentru
certificate și pentru revocarea acestora. Trebuie subliniată diferența dintre o infrastructură cu
chei publice și o aplicație care este doar capabilă să folosească serviciile de securitate puse la
dispoziție de aceasta ”[27].
1.3.1. Autentificarea și autorizarea prin certificate digitale
Pentru a putea accesa online sistemul informatic centralizat SIUI al CNAS, furnizorii de
servicii medicale și farmaceutice vor avea nevoie de certificate digitale emise de o autoritate
publică de certificare recunoscută de STS. Fiecare furnizor trebui să își înregistreze în SIUI
certificatele digitale care vor fi folosite de operatorii proprii pentru a accesa serviciile SIUI
online. În SIUI se vor crea conturi de utilizatori autorizați în SIUI pentru fiecare operator al
furnizorului, iar aceștia vor putea accesa sistemul online numai pe baza certificatului digital.
Certificate digitale sunt gestionate într -o bază de date dedicată prin intermediul unei aplicații de
administrare de către operatorii de la Casele de Asigurare Județene [27].
Certificatul digital trebuie instalat pe calculatorul pe care este instalată aplicația de
raportare și trebuie să fie accesibil aplicației prin mijloace de interconectare (instalare pe
sistemul de operare sau acces prin driver sistem la un eToken). Aplicația de raportare folo sește
certificatul pentru autentificarea și autorizarea cererilor online către SIUI prin intermediului
protocolului HTTPS/SSL [27].

14 Poarta de intrare în SIUI este securizată prin intermediul unui echipament hardware care
joacă rolul de firewall, accelerato r SSL și load -balancer, în același timp realizând și verificarea
certificatelor digitale prezentate de aplicațiile de raportare din punct de vedere al integrității și
valabilității la deschiderea unei noi sesiuni SSL prin HTTPS.
În urma verificării integri tății și valabilității certificatului, acceleratorul SSL transmite
mai departe cererea prin protocol HTTP către un server de autentificare și autorizare, parte
integrantă a SIUI, înglobând în header -ul HTTP și informațiile din certificatul digital necesare
pentru verificarea prin OCSP a stării de revocare certificatului digital.
Acest server verifică în baza de date dedicată, dacă certificatul digital a fost înregistrat de
către un utilizator autorizat al sistemului, iar dacă este formulează o cerere prin p rotocolul OCSP
către serviciul pus la dispoziție de STS. Acest serviciu verifică autenticitatea certificatului prin
interogarea serviciilor similare ale autorităților de certificare publice cu care STS are protocoale
de comunicare [27].
Serviciul de Teleco municații Speciale oferă ca parte a acestui sistem o componentă care
permite interogarea simultană a tuturor Autorităților de Certificare publice din România,
realizând astfel izolarea sistemului de eventuale modificări ale structurii sau componenței acest or
autorități. Această componentă trebuie să respecte, la rândul ei, caracteristicile legate de înalta
disponibilitate și scalabilitate la toate nivelurile ale sistemului SIUI.
Dacă certificatul digital nu este revocat, atunci serverul de autentificare și autorizare
verifică în baza de date tampon dacă furnizorul cu care este asociat utilizatorul nu are contractul
expirat. Ulterior transmite aplicației de raportare un token software (session -id-hash) care trebuie
folosit de aceasta la apelurile următoare pe sesiunea SSL curentă la sfârșitul URL -ului de apel,
pentru a indica sistemului că sesiunea a fost deja autorizată, evitând astfel verificarea excesivă a
certificatului care ar putea introduce penalizări de performanță semnificative [27].
Acceleratorul SSL folosește acest session -id-hash pentru a transmite cererile ulterioare
către serverele de aplicație SIUI. Aici hash -ul este verificat și în funcție de drepturile de acces se
va acorda accesul către serviciul Web.
În cazul în care unul dintre criteriile d e verificare de mai sus nu este respectat, atunci
sistemul întoarce un mesaj de eroare HTTP corespunzător:
401 – Unauthorized: Certificatul este expirat sau revocat, ori utilizatorul nu este autorizat
să acceseze sistemul SIUI.
403 – Forbidden: Certificatu l este valid, iar utilizatorul este autorizat să acceseze sistemul
online, dar cererea a fost respinsă datorită lipsei drepturilor de acces la un anumit serviciu Web

15 sau metodă a serviciului Web, de exemplu un medic nu va putea accesa serviciile destinate
farmaciștilor [27].
În acest context prin autentificare se înțelege confirmarea identității declarate a unui
utilizator, iar prin autorizare se înțelege procesul de acordare a accesului la resursele
informaționale din sistem numai utilizatorilor, aplicații lor, proceselor și altor sisteme care dețin
credențialele necesare. Practic la autentificare se verifică identitatea inițiatorului unei cereri de
acces, iar la autorizare se verifică existența unor drepturi pe baza cărora se permite sau nu
accesul la resur sele cerute [27].
Pentru a evita verificarea certificatului digital la fiecare apel aplicația de raportare trebuie
să implementeze un mecanism prin care să mențină deschisă sesiunea SSL, astfel încât ulterior
autentificării și autorizării apelurile către s erviciul Web să poată fi efectuate direct.
1.3.2. Semnătura digitală
Semnătura electronică reprezintă o informație în format electronic, care este atașată sau
logic asociată unor documente în formă electronică, de asemenea, având aceeași semnificație ca
și o semn ătură olografă. Semnatarul este definit ca fiind acea persoană care deține un dispozitiv
de creare a semnăturii electronice și care acționează, fie în nume propriu (persoană fizică), fie în
numele unui terț (persoană juridică, de exemplu).
O semnătura digi tală furnizează un grad mai mare de securizare decât o semnătură
olografă. Destinatarul mesajului semnat digital poate verifica atât faptul că mesajul original
aparține persoanei a cărei semnătură a fost atașată cât și faptul că mesajul n -a fost alterat,
intenționat sau accidental, de când a fost semnat [27].
Pentru ca o persoană să poată folosi semnătura electronică, este necesar ca în prealabil să
dobândească un certificat digital calificat care îi atestă identitatea. Certificatul digital reprezintă o
colecție de date în formă electronică și atestă legătura dintre datele de verificare a semnăturii
electronice și semnatarul ca persoană, confirmând identitatea acelei persoane. Certificatul
calificat este eliberat de către un furnizor de servicii de certifica re, legal constituit, numit
autoritate de certificare.
“Pentru a garanta non -repudierea datelor raportate în SIUI, fișierele de raportare vor
trebui să fie semnate electronic folosind aceleași certificate digitale ca și pentru autorizarea
accesului la sist em. Prin semnarea electronică a fișierelor de raportare se creează premisele
eliminării în viitor a raportărilor clasice pe hârtie și astfel simplificarea fluxurilor de documente,
care va duce la posibilitatea automatizării complete a procesului de raporta re și decontare ”[27].

16 Pentru ca o persoană să poată folosi semnătura electronică, este necesar ca în prealabil să
dobândească un certificat digital calificat care îi atestă identitatea. Certificatul digital reprezintă o
colecție de date în formă electroni că și atestă legătura dintre datele de verificare a semnăturii
electronice și semnatarul ca persoană, confirmând identitatea acelei persoane. Certificatul
calificat este eliberat de către un furnizor de servicii de certificare, legal constituit, numit
autoritate de certificare.
Fișierele XML generate de aplicația de raportare vor fi semnate electronic folosind
certificatul digital al utilizatorului care realizează raportarea, beneficiind astfel de toate
avantajele oferite de această tehnologie. Certificatul digital trebuie să fie instalat pe calculatorul
pe care este instalată aplicația de raportare și va fi accesibil aplicației prin mijloace de
interconectare (instalare pe sistemul de operare sau acces prin driver sistem de pe eToken) [27].
Pentru că fișier ul semnat electronic să poată fi raportat online este necesară în prealabil
urmarea pașilor din procedura de autentificare și autorizare. Aplicația folosește certificatul
pentru a deschide conexiunea online către SIUI prin intermediului protocolului HTTPS/ SSL.
După ce sistemul verifică certificatele digitale prezentate de aplicațiile de raportare din
punct de vedere al integrității și valabilității la deschiderea unei noi sesiuni SSL prin HTTPS,
acesta transmite mai departe cererea prin protocol HTTP către o aplicație Web de autentificare și
autorizare, înglobând în header -ul HTTP informațiile din certificatul digital necesare pentru
verificarea prin OCSP a stării de revocare certificatului digital.
Aplicația de autentificare verifică în baza de date tampon, dacă certificatul digital a fost
înregistrat de către un utilizator autorizat al sistemului, iar dacă este formulează o cerere prin
protocolul OCSP către serviciul pus la dispoziție de STS [27].
Pentru a putea face oricând dovada motivului de respingere s au invalidare a unei
raportări, sistemul păstrează o arhivă a tuturor fișierelor de raportare care au fost transmise,
indiferent dacă semnătura a fost sau nu validă [27].

17
Capitolul 2. Managementul Bazelor de Date
2.1. Sistem de gestionare a bazelor de date (DBMS)
Un DBMS este în esență o colecție de date interrelaționate și un set de programe pentru
accesarea acestor date. Această colecție de date se numește Baza de date care facilitează
stocarea, regăsirea și gestionarea informațiilor [13].
Un DBMS constă dintr -o colecție de date interrelaționate și un set de programe pentru
accesarea acestor date. Colectarea de date este denumită de obicei baza de date. Principalul
obiectiv al DBMS este de a oferi un mediu care să fie atât convenabil cât și eficient de utilizat în
preluarea și stocarea informațiilor din baza de date [19].
Sistemele de baze de date sunt concepute pentru a gestiona corpuri mari de informații.
Gestionarea datelor implică atât definirea structurilor de stocare a informațiilor, cât și furnizarea
de mecanisme de manipulare a informațiilor.
În plus, sistemul de baze de date trebuie să asigure siguranța informațiilor stocate, în
ciuda blocărilor sistemului sau a încercărilor de acces neautorizat. Dacă datele sunt partajate
între mai mulți utilizatori, sistemul trebuie să evite posibile rezultate anormale [19].
DBMS este un sistem software care gestionează bazele de date oferind facilități pentru
accesul și controlul organizației. DBMS este ca un operator pentru baza de date. Baza de date
este pasivă unde DBMS este activ. Oferă interfața dintre fișierul de date de pe disc și programul
care solicită procesarea [13].
2.1.1. Obiectivele DBMS
Obiectivul principal al unui DBMS este de a oferi un mediu convenabil pentru preluarea
și stocarea inform ațiilor din baza de date. Suporta mediul cu un singur utilizator și cu multi –
utilizatori [19].
• Asigurați stocarea în masă a datelor relevante.
• Facilitarea accesului la date pentru utilizator.
• Furnizeaza răspuns prompt la solicitările utilizatorului pentru date.
• Face cele mai recente modificări ale bazei de date disponibile imediat.
• Elimina datele redundante.
• Permite mai multor utilizatori să fie activi simultan.
• Permite dezvoltarea sistemului de baze de date.

18 • Protejeaza datele împotriva vătămărilor fizice și accesului neautorizat.
• Controlul corectitudinii, coerenței, integrității, securității etc.
2.1.2. Funcțiile DBMS
Conform Codd, un DBMS complet oferă opt funcții majore , anume [19]:
• Stocarea, regăsirea și actualizarea datelor: o bază de date p oate fi împărtășită
de mulți utilizatori, astfel DBMS trebuie să ofere vizualizări multiple
utilizatorilor și să le permită utilizatorilor să stocheze, să recupereze și să
actualizeze ușor și eficient.
• Dicționar și director de date: DBMS trebuie să mențină un dicționar de date
accesibil utilizatorului.
• Integritatea tranzacției: o tranzacție este o secvență de pași care constituie o
activitate comercială bine definită. Pentru a menține integritatea tranzacțiilor,
DBMS trebuie să ofere posibilitati utilizator ului sau programului de aplicație
de a defini limitele tranzacției, adică începutul și sfârșitul logic al tranzacțiilor.
DBMS ar trebui să efectueze apoi modificări pentru tranzacțiile de succes și
să respingă modificările pentru tranzacțiile esuate [19].
• Servicii de recuperare: DBMS trebuie să poată restaura baza de date în cazul
unei defecțiuni a sistemului. Sursele de defectare a sistemului includ erori de
operator și erori de program.
• Controlul simultaneitatii: Deoarece o bază de date este partajată d e mai mulți
utilizatori, doi sau mai mulți utilizatori pot încerca să acceseze aceleași date
simultan. Dacă doi utilizatori încearcă să actualizeze simultan aceeași
înregistrare de date, pot apărea rezultate eronate.
• Mecanisme de securitate: Datele trebui e protejate împotriva utilizării
necorespunzătoare sau rau intenționate. DBMS oferă mecanisme pentru
controlul accesului la date și pentru definirea acțiunilor care pot fi luate de
fiecare utilizator.
• Interfața de comunicare a datelor: Utilizatorii accese ază adesea o bază de date
cu ajutorul unor terminale de la distanță din rețeaua de telecomunicații. Un
monitor de telecomunicații este utilizat procesând fluxul de tranzacții către și
de la terminalele de la distanță. DBMS trebuie să furnizeze o interfață cu unul
sau mai multe monitoare de telecomunicații, astfel încât toate funcțiile
necesare să fie îndeplinite și sistemul să ajute [19].

19 • Servicii de integritate: DBMS trebuie să ofere facilități care să ajute
utilizatorii în introducerea datelor lor. O vari etate de verificări de editare și
constrângeri de integritate pot fi proiectate în DBMS și in interfețele sale
software. Aceste verificări sunt administrate în mod normal prin intermediul
dicționarului de date.
2.1.3. Componente ale unui DBMS
Un DBMS este o struc tură complexă care este utilizată pentru gestionarea, stocarea și
manipularea datelor și a metadatelor utilizate pentru a descrie datele. Este utilizat de o mare
varietate de utilizatori pentru a prelua și manipula datele aflate sub controlul acestora. Un sistem
este compus dintr -un set de componente interrelaționate [13].
1. Cel putin o persoană care deține și este responsabilă pentru baza de date.
2. Un set de reguli și relații care definește și guvernează interacțiunile dintre
elementele bazei de date.
3. Perso anele care introduc date în baza de date.
4. Persoanele care scot date din baza de date.
5. Baza de date în sine.
2.2. Proiectarea bazei de date
Proiectarea bazei de date presupune proiectarea structurii bazei de date care va fi folosită
pentru stocarea și gestionarea datelor, mai degrabă decât proiectarea software -ului DBMS. Odată
ce proiectarea bazei de date este finalizată, SGBD gestionează toate activitățile complicate
necesare pentru a transpune viziunea proiectantului asupra structurilor în structuri c are pot fi
utilizate pentru computer [22].
O bază de date slab proiectată tinde să genereze erori care pot conduce la decizii proaste.
În cele din urmă, o proiectare proastă a bazelor de date poate fi corectată de sine: organizațiile
care utilizează baze d e date slab proiectate eșuează adesea, deoarece managerii lor nu au acces la
informații în timp util [13].
Disponibilitatea unui DBMS face posibilă abordarea unor utilizări mult mai sofisticate
ale resurselor de date, dacă baza de date este proiectată pent ru a utiliza această putere
disponibilă. Tipurile de structuri de date create în baza de date și gradul relațiilor dintre ele joacă
un rol puternic în determinarea eficienței DBMS. Prin urmare, proiectarea bazelor de date devine
o activitate crucială.

20 Proiectarea bazelor de date este mult mai simplă atunci când folosim modele. Un model
de bază de date este o colecție de construcții logice utilizate pentru a reprezenta structura de date
și relațiile de date găsite în baza de date, adică abstractizări simplif icate ale evenimentelor sau
condițiilor din lumea reală. Dacă modelele nu sunt logice, proiectele de baze de date derivate din
acestea nu vor adduce beneficii sistemului de baze de date cu privire la informații eficiente
extrase dintr -o bază de date. „Mode lele bune oferă un design bun al bazelor de date care stă la
baza aplicațiilor bune” [13].
2.2.1. Obiectivele proiectarii bazelor de date
Proiectarea bazei de date implică în mod normal definirea atributelor logice ale bazei de
date care proiectează structura fiș ierelor bazei de date.
Principalele obiective ale proiectării bazelor de date sunt [19]:
1. Pentru a satisface cerințele de conținut de informații ale utilizatorului și aplicației
specificate.
2. Pentru a oferi un mod natural și ușor de înțeles a structurii info rmațiilor.
3. Pentru a susține cerințele de procesare și orice obiective de performanță, cum ar fi
i. Timp de raspuns
ii. Timp de procesare
iii. Spatiu de stocare
Obiectivul principal al proiectării bazei de date este să se asigure că baza de date
îndeplinește eficient c erințele de raportare a informațiilor catre utilizatori. Baza de date ar trebui
să fie proiectată astfel încât [22]:
i. Acesta elimină sau reduce redundanța datelor.
ii. Menține integritatea și independența datelor.
2.2.2. Vizualizare logică și fizică a bazei de date
În proiectarea bazelor de date, mai multe vizualizări ale datelor trebuie luate în
considerare împreună cu persoanele care le utilizează. Există trei vizualizări [19]:
1. Vizualizarea logică generală
2. Vizualizarea logică a programului
3. Vizualizarea fizică
Vizualizarea logică este cum arată datele, indiferent de modul în care sunt stocate, în
timp ce vizualizarea fizică este modul în care datele există în stocarea fizică, tratează modul în
care datele sunt stocate, accesate sau legate de alte date.

21 Vizualiza rea logică generală (schemă) ajută SGBD să decidă la ce date în stocare ar
trebui să acționeze așa cum solicită programul de aplicație.
Un SGBD este o colecție de fișiere interrelaționate și un set de programe care permit
utilizatorilor să acceseze și să modifice aceste fișiere. Un scop major al unui sistem de baze de
date este de a oferi utilizatorilor o vedere abstractă a datelor, adică sistemul ascunde anumite
detalii despre modul în care datele sunt stocate și întreținute. [22]
2.2.3. Arhitectura sistemelor b azelor de date
Abstragerea datelor : Mulți utilizatori ai sistemului de baze de date nu sunt instruiți in
programare si utilizarea avansata a calculatorului, dezvoltatorii ascund complexitatea bazelor de
data fata de utilizatori prin mai multe niveluri de a bstractizare, pentru a simplifica interacțiunea
utilizatorilor cu sistemul. Arhitectura este împărțită în trei niveluri generale: intern, conceptual și
extern [19].
a. Nivel intern / fizic: Nivelul intern este cel mai apropiat de stocarea fizică, adică unu l
preocupat de modul în care datele sunt stocate efectiv. Este cel mai scăzut nivel de abstractizare
care descrie modul în care datele sunt stocate efectiv. La nivel fizic, sunt descrise în detaliu
structuri complexe de date de nivel scăzut.
b. Nivel conce ptual / logic: este un „nivel de indirecție” între intern și extern. Următorul
nivel superior de abstractizare descrie ce date sunt stocate în baza de date și ce relații există între
aceste date. Întreaga bază de date este astfel descrisă în termenii unui număr mic de structuri
relativ simple. Acest nivel este utilizat de administratorii bazei de date (DBA), care trebuie să
decidă ce informații trebuie păstrate în baza de date [22].
c. Nivel extern / de vizualizare: Nivelul extern este cel mai apropiat de utilizatori, adică
cel care este raspunzator de modul în care datele sunt vizualizate de utilizatori individuali. Este
cel mai înalt nivel de abstractizare care descrie doar o parte din întreaga bază de d ate. În ciuda
utilizării unor structuri mai simple la nivel logic, rămâne o oarecare complexitate, din cauza
dimensiunii mari a bazei de date. Mulți utilizatori ai sistemului de baze de date nu vor fi
preocupați de toate aceste informații. În schimb, aceșt i utilizatori trebuie să acceseze doar o parte
a bazei de date, astfel încât interacțiunea lor cu sistemul să fie simplificată. Sistemul poate oferi
multe vizualizări pentru aceeași bază de date [22].
Dacă nivelul extern este preocupat de vizualizările in dividuale ale utilizatorului, nivelul
conceptual poate fi gândit ca definind o vedere a comunității utilizatorului. Cu alte cuvinte, vor
exista multe „vizualizări externe”, fiecare constând dintr -o reprezentare mai mult sau mai puțin
abstractă a unei porți uni a bazei de date și va exista o singură „viziune conceptuală”, constând

22 dintr -o reprezentare abstractă a bazei de date în integralitatea ei. De asemenea, va exista o
singură „vizualizare internă”, reprezentând baza de date totală ca fiind stocată efecti v.
Instanțe și scheme : bazele de date se schimbă în timp, pe măsură ce informațiile sunt
introduse sau șterse. Colecția de informații stocate în baza de date într -un anumit moment se
numește o instanță a bazei de date. Designul general al bazei de date se numește schema bazei de
date. Schemele sunt modificate rar, chiar deloc.
Vizualizare a la fiecare dintre aceste niveluri este descrisă de o Schemă. O schemă este un
contur sau un plan care descrie înregistrările și relațiile existente în vizualizare [22].
Sistemele de baze de date au mai multe scheme, partiționate în funcție de nivelurile de
abstractizare. La nivelul cel mai scăzut este schema fizică; la nivel intermediar este schema
logică; iar la cel mai înalt nivel este o subschema. În general, sistemul de baze de date acceptă o
schemă fizică, o schemă logică și mai multe subscheme.
Independența datelor : Abilitatea de a modifica o definiție a schemelor la un nivel fără a
afecta o definiție a schemei în următorul nivel superior se numește independența date lor. Există
două niveluri de independență a datelor, adică [22].
a. Independența datelor fizice: este posibilitatea de a modifica schema
fizică fără a provoca rescrierea programelor. Ocazional, modificările
la nivel fizic sunt necesare pentru a îmbunătăți per formanța.
b. Independența datelor logice: este posibilitatea de a modifica schema
logică fără a face rescrierea programelor. Modificările la nivel logic
sunt necesare ocazional ori de câte ori structura logică a bazei de
date este modificată.
Independența log ică a datelor este mai dificil de realizat decât independența datelor
fizice, deoarece programele software depind în mare măsură de structura logică a datelor la care
au acces.
Limbajul bazei de date: Sublanguage de date (DSL) este un subset al limbii tota le adică
în legătură cu obiectele și operațiunile bazei de date. DSL este un utilizator / limbă de interogare
care este încorporat într -o limbă gazdă. În principiu, orice DSL dat este într -adevăr o combinație
de două limbi [22]:
a. Data Definition Language (DDL): este limbajul care specifică schema bazei de date. O
schemă a bazei de date este specificată de un set de definiții. Această definiție include toate
entitățile și atributele asociate acestora, precum și relațiile dintre entități. Rezultatul compilă rii
declarațiilor DDL este un set de tabele stocate într -un fișier special numit dicționar de date sau

23 director de date, care conține metadate, adică date despre date. Acest fișier este consultat înainte
ca datele reale să fie citite sau modificate în sist emul de baze de date.
Structura de stocare și metodele de acces utilizate de sistemul de baze de date sunt
specificate de un set de definiții într -un tip special de DDL numit limbaj de stocare și definiție a
datelor.
b. Data Manipulation Language (DML): es te limbajul care este utilizat pentru a exprima
interogări și actualizări de date, adică manipularea datelor din baza de date. DML ajută în [22]
– preluarea informațiilor stocate în baza de date
– inserarea de noi informații în baza de date
– ștergerea informațiilor din baza de date
– modificarea informațiilor stocate în baza de date existent
Un DML este un limbaj care permite utilizatorilor să acceseze sau să manipuleze datele.
Există practic două tipuri:
i. DML -uri procedurale: solicită utilizatorului să specifice ce date sunt necesare și cum să
obțină aceste date.
ii. DML -uri non -procedurale: solicită utilizatorului să specifice ce date sunt necesare fără
a specifica cum să obțină aceste date.
Mapare : Există două niveluri de mapare [22]:
i. dintre niveluril e externe și conceptuale ale sistemului; și
ii. între nivelurile conceptuale și cele interne.
Maparea conceptuală / internă definește corespondența dintre vizualizarea conceptuală și
baza de date stocată. Maparea externă / conceptuală definește corespondența dintre o anumită
vizualizarea externă și cea conceptuală.
DBMS este software -ul care se ocupă de tot accesul la baza de date. Conceptual, ceea ce
se întâmplă este [22]:
1. Un utilizator emite o solicitare de acces, folosind unele limbaje de manipulare a datelor
(DML);
2. DBMS interceptează cererile și îl interpretează;
3. DBMS inspectează, la rândul său, schema externă, maparea externă / conceptuală,
schema conceptuală, maparea conceptuală / internă și definiția structurii de stocare; și
4. DBMS efectueaz ă operațiunile necesare pe baza de date stocată.

24 2.2.4. Structuri de stocare:
Structurile de stocare descriu modul în care datele pot fi organizate în stocarea secundară,
adică suporturi cu acces direct, cum ar fi discuri, etc.
Operațiunile utilizatorilor sunt ex primate (prin intermediul DML) în termeni de
înregistrări externe și trebuie convertite de SGBD în operațiuni corespunzătoare în înregistrări
interne sau stocate. Aceste operațiuni ulterioare trebuie transformate, la rândul lor, în operații la
nivel de har dware real, adică în operații pe înregistrări fizice. Componenta responsabilă pentru
această conversie internă / fizică se numește metodă de acces. Funcția sa este de a ascunde toate
detaliile dependente de dispozitiv din SGBD și de a prezenta SGBD cu o in terfață stocată.
Interfața stocată corespunde astfel nivelului intern, la fel cum interfața utilizator corespunde
nivelului extern. Interfața fizică corespunde nivelului hardware real [22].
Interfața stocată permite DBMS să vizualizeze structura de stocare ca o colecție de fișiere
stocate, fiecare constând din toate aparițiile unui tip de înregistrare stocată. În mod specific,
DBMS știe (a). ce fișiere stocate există și, pentru fiecare, (b) structura înregistrării stocate
corespunzătoare, (c) câmpurile stoc ate, dacă este cazul, pe care sunt secvențiate și (d) câmpurile
stocate, dacă există, care pot fi utilizate ca argumente de căutare pentru acces direct. Aceste
informații vor fi specificate ca parte a definiției structurii de stocare [22].
2.2.5. Faze în proiecta rea bazelor de date
Prima fază : Scopul general al studiului inițial al bazei de date este acela de [19]:
a. analiza situației organizației / sistemului
b. definrea problemelor și constrângerilor
c. definirea obiectivelor
d. definirea domeniului de aplica re și limitelor.
A doua fază : A doua fază se concentrează pe proiectarea modelului bazei de date care va
sprijini operațiunile și obiectivele organizației [19].
În această fază, putem identifica șase faze principale ale proiectării bazei de date:
I. Culegerea și analiza cerințelor
II. Proiectarea conceptuală a bazei de date
III. Alegerea DBMS
IV. Maparea modelelor de date
V. Proiectarea bazelor de date fizice
VI. Implementarea sistemului de baze de date

25 I. Design conceptual: implică două activități paralele
a. Proiectare a schemei conceptuale
b. Proiectarea tranzacției
a. Prima activitate a proiectării conceptuale examinează cerințele de date rezultate din
faza 1 și produce o schemă de baze de date conceptuale.
b. A doua activitate. Proiectarea tranzacției examinează aplic ațiile bazei de date analizate
în faza 1 și produce specificații la nivel înalt pentru prezentare. Obiectivul fazei 2 este de a
produce o schemă conceptuală pentru baza de date, adică independent de un SGBD specific [22].
În această etapă, modelarea datelor este utilizată pentru a crea o structură abstractă a
bazei de date care reprezintă obiectele din lumea reală în cel mai realist mod posibil. Modelul
conceptual trebuie să includă o înțelegere clară a tranzacției sau a sistemului și a domeniilor sale
de fu ncționare. Acest design este independent de software și hardware [22].
i. Analiză și cerințe de date: înainte de a putea proiecta eficient o bază de date, trebuie să
cunoaștem cât mai detaliat așteptările utilizatorilor și ale utilizatorilor viitori ai baz ei de date.
Procesul de identificare și analiză a utilizatorilor intenționați se numește „Culegerea și analiza
cerințelor”.
Primul pas în proiectarea conceptuală este descoperirea caracteristicilor datelor.
Caracteristicile corespunzătoare ale elementelor de date sunt cele care pot fi realizate în
informații adecvate. Prin urmare, designerii trebuie să se axeze pe [22]:
A. nevoi de informatii;
b. utilizatori de informații;
c. surse de informare; și
d. constituirea informației.
Pentru a dezvolta un model de date exact, proiectantul trebuie să aibă o înțelegere
completă a datelor organizației. În consecință, proiectantul trebuie să identifice obiectivele,
regulile organizației și să analizeze impactul acestora asupra naturii și rolului datelor.
ii. Modelarea și normalizarea relațiilor dintr entitati: înainte de a crea modelul E -R
(model de date), proiectantul trebuie să comunice și să aplice standardele adecvate pentru a fi
utilizate în documentația proiectării. Eșecul în standardizarea documentației înseamnă deseori un
eșec în comunicarea ulterioară. Și eșecurile în comunicare duc adesea la o muncă deficitară de
proiectare.

26 iii. Verificarea modelului de date: Modelul E -R trebuie să fie verificat cu privire la faptul
că procesele propuse de sistem pot fi suport ate de modelul bazei de date [22].
Verificarea necesită ca modelul să poată fi trecut printr -o serie de teste împotriva:
a. Vizualizările de date ale utilizatorului final și tranzacțiile lor necesare:
SELECTAREA, INSERAREA, ACTUALIZAREA și ȘTERGEREA operațiun ilor,
interogărilor și rapoartelor.
b. Căile de acces, securitatea și controlul concurentei.
c. Cerințele și constrângerile de date impuse de sistem.
iv. Design -ul bazei de date distribuită: o bază de date distribuită stochează datele legate în
mod logic în două sau mai multe site -uri independente fizic conectate prin intermediul unei
rețele de calculatoare. Porțiuni de proiectare ale unei baze de date pot sta în diferite locații.
Procesele care accesează baza de date pot varia, de asemenea, de la o locație l a alta.
II. Selecția software -ului DBMS: Selectarea software -ului DBMS este esențială pentru
buna funcționare a sistemelor informaționale. În consecință, avantajele și dezavantajele propuse
de software -ul DBMS trebuie studiate cu atenție. Utilizatorul fina l trebuie să fie conștient de
limitările atât ale SGBD cât și ale bazei de date pentru a evita așteptările false [22].
Factorii care afectează decizia de cumpărare a DBMS sunt:
(I) Cost,
(II) Caracteristici și instrumente DBMS,
(III) Modelul de date de bază,
(IV) Portabilitat e și
(V) Cerințele hardware ale DBMS
III. Proiectare logică: Proiectarea logică este utilizată pentru a transpune proiectul
conceptual în modelul intern pentru un SGBD selectat (cum ar fi DB2, SQL Server, Oracle, IMS,
Informix, Access, Ingress și așa mai depar te). Designul logic urmează decizia de a utiliza un
model de bază de date specific (ierarhic, de rețea sau relațional). Odată identificat modelul bazei
de date, putem să mapăm designul conceptual pe un design logic adaptat modelului de bază de
date selecta t. În această etapă, designul logic depinde de software. Aceasta include maparea
tuturor obiectelor din model la constructele specifice utilizate de software -ul selectat al bazei de
date. Dreptul de utilizare a bazei de date este, de asemenea, specificat î n faza de proiectare logică
[22].

27 Pe scurt, designul logic transpune modelul conceptual independent de software într -un
model dependent de software, prin definirea definițiilor de domeniu corespunzătoare, tabelelor
necesare și restricțiile de acces necesar e.
IV. Proiectare fizică: Etapa este acum setată pentru a defini cerințele fizice care permit
sistemului să funcționeze în mediul hardware selectat.
Proiectarea fizică este procesul de selectare a caracteristicilor de stocare și acces la date
ale bazei de date. Caracteristicile de stocare sunt o funcție a tipurilor de dispozitive acceptate de
hardware, a tipului metodelor de acces la date acceptate de sistem și a DBMS. Proiectarea fizică
afectează nu numai locația datelor în dispozitivul (dispozitivele) de stocare, ci și performanța
sistemului [22].
V. Implementarea sistemului de baze de date: După crearea bazei de date, datele trebuie
încărcate în tabelele bazei de date. Dacă datele sunt în prezent stocate într -un format diferit de
cel cerut de noul SGBD, datele trebuie convertite înainte de a fi încărcate.
În faza de implementare și încărcare, trebuie să abordăm, de asemenea, performanța,
securitatea, backup -ul și recuperarea, integritatea, standardele companiei și controlul
simultaneitatii.

28 Capitolul 3. Prezentare Android
“Platformele mobile au crescut foarte rapid în popularitate în ultimii ani. În același timp,
vulnerabilitățile și programele malware au evoluat, afectând noul peisaj mobil. Pentru a răspunde
acestui nou set de amenințări , este necesar că tehnicile și instrumentele de securitate existente să
se adapteze la noua situație. Ca urmare, tehnicile, instrumentele și procesele actuale de efectuare
a analizelor criminalistice în rețele și sisteme trebuie să acopere și platformele m obile ” [26] .
3.1. Arhitectura sistemului de operare android
Sistemul de operare Android cuprinde diverse componente software care se aranjează
într-o stivă.
A. Kernel -ul Linux
Kernel -ul Linux este “stratul inferior al sistemului de operare Android. Acesta oferă
funcționalitățile de bază ale sistemului de operare precum managementul proceselor și al
dispozitivului și de asemenea și o listă de drivere ce facilitează interfațarea sistemului de operare
cu dispozitivele periferice ” [26] .
B. Librării
Următorul nivel în sti vă după kernel este nivelul librăriilor. Acesta oferă o gamă variată
de biblioteci Java construite special pentru Android care asigură buna funcționare a sistemului de
operare [26].
Tabel 3.1. Librarii utilizate de Android
Librărie Utilizare
SQLite Accesează datele publicate de furnizorii de conținut și include clasele de
management a bazelor de date SQLite.
SSL Asigură securitatea pe internet
OpenGL Furnizează interfața Java pentru API -ul de redare grafică OpenGL / ES 3D.
Media
framework Oferă di ferite codecuri media care permit înregistrarea și redarea diferitelor
formate media
WebKit Este motorul de browser folosit pentru a afișa conținutul conținutul HTML
C. Android Run time

29 Android Run time este a treia componentă a arhitecturii Android și este poziționată pe al
doilea nivel, la fel ca librăriile.
Acesta pune la dispoziție cea mai importantă componentă a sistemului de operare, mașina
virtuală Dalvik. Mașina virtuală Dalvik este similară cu JVM, singura diferență fiind că este
proiectată și optim izată pentru Android [26].
D. Framework -ul de aplicații
Este componentă de pe penultimul nivel în stiva arhitecturală a sistemului de operare
Android și aceasta interacționează direct cu aplicațiile. Framework -ul gestionează funcțiile de
bază ale dispozitivului Android precum gestionarea resurselor, gestionarea apelurilor, etc. [26]
Câteva componente importante ale acestuia sunt următoarele:
Tabel 3.2. Framework -ul de aplicații utilizate de Android
Bloc Utilizare
Activity
Manager Acest bloc este f olosit pentru gestionarea ciclului complet al activităților
aplicațiilor
Content
Providers Acest bloc este folosit pentru gestionarea partajarea datelor între două
aplicații
Telephony
Manager Acest bloc este folosit pentru gestionarea tuturor apelurilor vocale
Location
Manager Acest bloc este folosit pentru gestionarea locațiilor obținute folosind
sistemul GPS sau info -celula
Resource
Manager Acest bloc este folosit pentru gestionarea diferitelor tipuri de resurse
folosite de aplicațiile android
E. Aplicațiile
Aplicațiile sunt create de utilizatori sau de dezvoltatori și sunt instalate pe nivelul de
aplicații.
Aplicațiile oferă mai multe puncte de intrare.
“Aplicațiile Android sunt construite ca o combinație de componente distincte care pot fi
invoca te individual. De exemplu, o activitate individuală oferă un singur ecran pentru o interfață
cu utilizatorul și un serviciu realizează independent lucrul în fundal.

30 De la o componentă poate porni o altă componentă utilizând un intent. Este posibilă chiar
și pornirea unei componente dintr -o aplicație diferită, cum ar fi o activitate într -o aplicație de
hărți pentru a afișa o adresă. Acest model oferă mai multe puncte de intrare pentru o singură
aplicație și permite oricărei aplicații să se comporte ca defaul t al utilizatorului pentru o acțiune
pe care alte aplicații o pot invoca ” [26] .
Aplicațiile se adaptează la diferite dispozitive.
Android oferă un framework adaptiv care permite să furnizarea de resurse unice pentru
diferite configurații de dispozitive. De exemplu, pot fi create diferite fișiere de format XML
pentru diferite dimensiuni ale ecranului, iar sistemul determină ce aspect să aplice în funcție de
dimensiunea ecranului dispozitivului [26].
Poate fi realizată interogarea disponibilității caracterist icilor dispozitivului în timpul
executării, dacă anumite caracteristici ale aplicației necesită un anumit hardware, cum ar fi o
cameră foto. Dacă este necesar, pot fi declarate și funcțiile de care aplicația are nevoie, astfel
încât piețele aplicațiilor, c um ar fi că Magazinul Google Play, să nu permită instalarea pe
dispozitive care nu acceptă acea facilitate [26].
3.2. Permisiunile de sistem
“Pentru a asigura securitatea sistemului și a utilizatorilor, Android solicită aplicațiilor să
ceară permisiuni înainte ca acestea să poată utiliza anumite date și caracteristici de sistem. În
funcție de gradul de sensibilitate al zonei, sistemul poate acorda permisiunea în mod automat sau
poate cere utilizatorului să aprobe cererea ” [26] .
A. Solicitarea permisiunilor
“O aplic ație simplă Android nu are asociată nici o permisiune în mod implicit, ceea ce
înseamnă că nu poate face nimic care ar avea un impact negativ asupra experienței utilizatorului
sau asupra oricăror date de pe dispozitiv. Pentru a utiliza funcțiile protejate ale dispozitivului,
trebuie incluse una sau mai multe etichete <uses -permission> în fișierul manifest al aplicației ”
[26].
De exemplu, o aplicație care trebuie să monitorizeze mesajele SMS primite ar specifica:
<manifest
Xmlns: android="http://schemas.android.com/apk/res
/android"
Package -'com. Android.app. Myapp" > <uses -permission

31 Android: name="android. Permission. RECEIVE_SMS"/></manifest>
“Dacă aplicația listează permisiunile normale în fișierul său manifest (adică permisiun i
care nu prezintă un risc prea mare pentru confidențialitatea utilizatorului sau funcționarea
dispozitivului), sistemul acordă automat acele permisiuni. Dacă aplicația afișează permisiuni
periculoase în fișierul său manifest (adică permisiuni care ar pute a afecta confidențialitatea
utilizatorului sau funcționarea normală a acestuia), sistemul îi cere utilizatorului să acorde în
mod explicit acele permisiuni. Modul în care Android lansează cererile depinde de versiunea
sistemului vizată de aplicație ” [26]:
– Dacă dispozitivul rulează Android 6.0 (nivel API 23) sau mai mare, iar
targetSdkVersion a aplicației este de 23 sau mai mult, aplicația solicită permisiuni din
partea utilizatorului în timpul execuției. Utilizatorul poate revoca permisiunile oricând,
astfe l încât aplicația trebuie să verifice dacă are permisiunile de fiecare dată când
accesează API -urile protejate prin permisiune.
– Dacă dispozitivul rulează Android 5.1.1 (nivel 22 API) sau mai mic, sau
targetSdkVersion a aplicației este de 22 sau mai puțin, sistemul solicită utilizatorului să
acorde permisiuni atunci când utilizatorul instalează aplicația. Dacă se adaugă o nouă
permisiune la o versiune actualizată a aplicației, sistemul îi cere utilizatorului să acorde
această permisiune atunci când utilizat orul actualizează aplicația. După ce utilizatorul
instalează aplicația, singura modalitate prin care poate revoca permisiunea este
dezinstalarea aplicației [26].
“De cele mai multe ori neacordarea unei permisiuni rezultă în lansarea către aplicație a
unei SecurityException. În orice caz, acest lucru nu este garantat să apară în toate cazurile. De
exemplu, metoda sendBroadcast (Intent) verifică permiliunile pe măsură ce datele sunt livrate
către fiecare receptor, după ce se returnează apelul metodei, astfel încât nu va fi întoarsă o
excepție dacă nu au fost oferite anumite permisiuni. În aproape toate cazurile, lipsa unei
permisiuni va fi listată în logul sistemului ” [26] .
Permisiunile puse la dispoziție de sistemul Android pot fi găsite în clasa Manifest.
Permission. Orice aplicație poate să definească și să -și impună propriile permisiuni, deci aceasta
nu este o listă comprehensivă a tuturor permisiunilor posibile.
O permisiune particulară poate fi impusă într -un număr de locuri în timpul execuției
programul ui:
– În momentul unei apelări în sistem, pentru a împiedica o aplicație să execute anumite
funcții.

32 – Când începe o activitate, pentru a împiedica aplicațiile să lanseze activități ale altor
aplicații.
– La difuzarea și recepția unui broadcast, pentru a control a cine poate recepționa sau cine
poate trimite un broadcast.
– Când se accesează și se operează pe un furnizor de conținut.
– Pornirea sau asocierea la un serviciu.
B. Ajustări automate ale permisiunilor
“De-a lungul timpului, platformelor le pot fi adăugate noi restricții, astfel încât, pentru a
utiliza anumite API -uri, aplicația trebuie să solicite o permisiune pe care nu o avea în trecut.
Deoarece aplicațiile existente presupun accesul la aceste interfețe API este disponibil în mod
gratuit, Android poate aplica noua solicitare de permisiune în manifestul aplicației, pentru a evita
ruperea aplicației pe noua versiune de platformă. Android ia decizia dacă o aplicație ar putea
avea nevoie de permisiune pe baza valorii furnizate pentru atributul targetSdkVersion. Da că
valoarea este mai mică decât versiunea în care a fost adăugată permisiunea, atunci Android
adaugă permisiunea ” [26] .
De exemplu, permisiunea WRITE_EXTERNAL_STORAGE a fost adăugată în
nivelul 4 al API pentru a restricționa accesul la spațiul de stocare partajat. Dacă target.
SdkVersion este 3 sau mai mic, această permisiune este adăugată aplicației pe versiuni mai noi
de Android.
Dacă în aplicație este adăugată automat o permisiune, listarea de aplicații din Google
Play afișează aceste permisiuni suplime ntare, chiar dacă este posibil ca aplicația să nu le solicite
efectiv.
Pentru a evita acest lucru și pentru a elimina permisiunile implicite de care nu este
nevoie, trebuie actualizat întotdeauna targetSdkVersion la cea mai recentă versiune. Se poate
verif ica ce permisiuni au fost adăugate cu fiecare versiune în documentația Build.
VERSION_CODES [26].
Permisiunile curente ale unei aplicații definite în sistem pot fi vizualizate folosind
aplicația Settings și comanda shell adb shell prin list permissions.
C. Permisiunea necesară pentru a instala aplicații necunoscute
Dacă aplicația vizează Android 8.0 (nivel de API 26) sau mai mare și declanșează
instalările APK utilizând API -ul de instalare a pachetelor, trebuie să adăugați permisiunea
REQUEST_INSTALL_PACKAGES, așa cum se arată în următorul fragment de cod:

33 <manifest>
<uses -permission
Android: name="android. Permission. REQUES T_INSTALL_PACKAGES"/>
<application>
</application>
</manifest>
D. Permisiuni Normale și Permisiuni „Periculoase”
Permisiunile de sistem sunt împărțite în mai multe niveluri de protecție. Cele două
niveluri de protecție cele mai importante care trebuie cunoscute sunt permisiunile normale și
„periculoase”:
“Permisiunile normale acoperă zonele în care aplicația trebuie să acceseze date sau
resurse în afara spațiului de lucru al aplicației, dar în care există foarte puține riscuri pentru
confidențialitatea utilizatorului sau pentru funcționarea altor aplicații. De exemplu, permisiunea
de a seta fusul orar este o permisiune obișnuită. Dacă o aplicație declară că are nevoie de o
permisiune obișnuită, sistemul acordă automat permisiunea aplicației ” [26] .
“Permisiunile „periculoase” acoperă zonele din care aplicația dorește date sau resurse
care implică informațiile private ale utilizatorului sau ar putea afecta datele stocate de utilizator
sau funcționarea altor aplicații. De exemplu, abilitatea de a citi contactele utilizatorului este o
permisiune periculoasă. Dacă o aplicație declară că are nevoie de o permisiune “periculoasă” ,
utilizatorul trebuie să acorde în mod explicit permisiunea aplicației ” [26] .
E. Grupuri de permisiuni
Toate permisiunile de sistem periculoase pentru Android aparțin grupurilor de
permisiune. Dacă dispozitivul rulează Android 6.0 (API -ul 23) și targetSdkVer sion a aplicației
este de 23 sau mai mult, următorul comportament de sistem se aplică când aplicația solicită o
permisiune „periculoasă”.
“Dacă o aplicație solicită o permisiune „periculoasă” listată în fișierul manifest și
aplicația nu are în prezent perm isiuni în grupul de permisiuni, sistemul afișează o casetă de
dialog către utilizatorul care descrie grupul de permisiuni pe care aplicația dorește să îl acceseze.
Caseta de dialog nu descrie permisiunea specifică din grupul respectiv. De exemplu, dacă o
aplicație solicită permisiunea READ_CONTACTS, caseta de dialog a sistemului spune că
aplicația are nevoie de acces la contactele dispozitivului. În cazul în care utilizatorul acordă
aprobarea, sistemul oferă aplicației doar permisiunea pe care o solicită ”[26].

34 Dacă o aplicație solicită o permisiune „periculoasă” afișată în fișierul manifest și aplicația
are deja o altă permisiune „periculoasă” în același grup de permisiuni, sistemul îi acordă imediat
permisiunea fără nici o interacțiune cu utilizatorul. De exemplu, dacă o aplicație a solicitat
anterior și a primit permisiunea READ_CONTACTS și apoi solicită WRITE_CONTACTS,
sistemul îi acordă imediat permisiunea.
Orice permisiune poate aparține unui grup de permisiuni, inclusiv permisiunile și
permisiunile no rmale definite de aplicație. Cu toate acestea, un grup de permisiuni afectează
numai experiența utilizatorului dacă permisiunea este periculoasă (grupul de permisiuni pentru
permisiuni obișnuite poate fi ignorat) [26].
Dacă dispozitivul rulează Android 5.1 (nivel 22 API) sau mai mic, sau targetSdkVersion
a aplicației este de 22 sau mai puțin, sistemul solicită utilizatorului să acorde permisiuni în
timpul instalării. Încă o dată, sistemul îi spune utilizatorului doar de ce grupuri de permisiuni are
nevoie a plicația, și nu permisiunile individuale.
3.3. Gestionarea credențialelor
Sistemul Android pune la dispoziție după moduri de gestionare a credențialelor, prin
utilizarea Authentication Manager sau Shared Preferences.
Account Manager permite partajarea credenți alelor între mai multe aplicații și servicii.
Utilizatorii introduc credențialele pentru fiecare cont o singură dată – aplicațiile cu permisiunea
USE_CREDENTIALS pot interoga account manager pentru a obține un token de autentificare
pentru cont.
Un autenti ficator solicită credențialele de la utilizator, le validează cu un server din cloud
și le stochează în account manager.
Android pune la dispoziție aplicațiilor o cale simplă de a stoca informațiile utilizatorilor,
precum numele contului și credențialele, folosind utilitatea SharedPreferences. Când o aplicație
este lansată, se face o cerere către componenta PreferenceManager pentru
DefaultSharedPreferences (numele de utilizator și parolă) [26].
Aceasta este o soluție bună pentru o aplicație care nu are o c omponentă specifică
(autentificator) care să se autentifice cu un serviciu back -end. Cu toate acestea, această
informație este scrisă în clar în directorul shared_prefs cu numele de fișier
applicationname_preferences.xml. Chiar dacă acest fișier are acces limitat la citire și scriere,
dacă un spyware rulează în fundalul aplicației, nimic nu va împiedica divulgarea acestor
informații sensibile.

35 3.4. Criptarea
“Android oferă un cadru de execuție bogat. Acest cadru oferă acces la o varietate de
subsisteme, cum ar f i interfețele grafice ale utilizatorilor, rețelele sau sub¬sistemele de telefonie
și de mesagerie. Subsistemul relevant pentru această ramură este Java Cryptography Architecture
(JCA). Această arhitectură standardizează modul în care dezvoltatorii de aplic ații pot utiliza
algoritmi criptografici. În acest scop, așa -numiții furnizori de servicii criptografice (CSP) sunt
înregistrați la JCA. Un CSP este un pachet care oferă implementări de algoritmi criptografici,
cum ar fi codurile de autentificare a mesajel or, scheme de criptare sau algoritmi de generare a
cheilor. Această arhitectură modularizată le permite distribuitorilor și dezvoltatorilor să instaleze
și să utilizeze în mod diferit CSP -uri diferite în paralel sau să înlocuiască unul cu celălalt, atâta
timp cât furnizează implementări pentru aceiași algoritmi ” [26].
De exemplu, în timp ce Oracle Java conține SunJCE ca CSP implicit, Android (de la
versiunea 2.1) utilizează BouncyCastle ca furnizor prestabilit de servicii criptografice. Cifrurile
bloc, schemele de criptare simetrică și asimetrică sunt accesibile unei aplicații prin API -ul
Cipher. Pentru a obține o instanță a unei scheme specifice de criptare, dezvoltatorul apelează
metoda implicită Cipher. GetInstance și oferă o transformare ca arg ument al acesteia.
“O transformare este un șir care specifică numele algoritmului, cifrul și schema de
umplere utilizată. De exemplu, pentru a obține un obiect de cifru care utilizează AES în modul
CBC cu padding PKCS5, dezvoltatorul va specifica transform area ca:
AES/CBC/PKCS5Padding. Numai partea de algoritm este obligatorie. Furnizorul de securitate
menține valorile implicite pentru modul cifru, precum și schema de umplere în cazul în care
dezvoltatorul alege să omită aceste valori ” [26].
Din păcate, Jav a și Android au ales ca valori implicite ECB și PKCS7Padding în cazul în
care este specificat doar algoritmul de criptare AES.
Astfel, un dezvoltator care specifică doar cifrul AES a cărui eficiență este discutabilă,
riscă să se pună într -o situație potenț ial nesigură în care se folosește cifrul bloc ECB.
3.5. Malware și probleme de securitate
Telefoanele mobile au devenit o țintă ușoară pentru atacurile informatice. Aceste conțin
un volum enorm de date de la contacte personale la e -mail-uri și este deasemenea p osibil să
realizeze variate tranzacții online.

36 Un malware este orice cod compromițător sau software care este proiectat să
îndeplinească anumite funcții fără acordul utilizatorului. Joanna Rutkowska definește malware -ul
ca fiind:
Malware este o bucată de cod care schimbă comportamentul fie al kernel -ului sistemului
de operare sau al unor aplicații vulnerabile, fără acordul utilizatorului și în așa fel încât este
imposibilă detectarea acestor schimbări folosind capabilitățile documentate ale sistemului de
operare sau ale aplicației.
Malware este împărțit în funcție de modul în care afectează buna funcționare a
sistemului. Astfel, sunt patru categorii de malware [26]:
• Virus: – Un virus este definit ca un program distructiv sau rău intenționat căruia îi
lipsește capacitatea de a se auto -reproduce.
• Worm: – Este un cod rău intenționat ce poate controla o vulnerabilitate a
sistemului său o rețea pentu a se multiplica automat pe un alt sistem.
• Trojan: – Un Trojan permite atacatorului să obțină acces neutorizat sa u acces la
distanță la un sistem în timpul în care pare să realizeze o operație cerută de
utilizator.
• Spyware: – Această aplicație distructivă se ascunde de utilizator în tip ce
colectează informații despre acesta fără acordul lui.
O clasificare a atacuril or destinate telefoanelor mobile este următoarea [26]:
• Ad-ware – include reclamele de pe telefoanele mobile care sunt, de fapt, malware.
• Direct Payoff – constă în malware care trimite SMS -uri fără acordul utilizatorului.
• Destructive – Un exemplu de astfel de atac este ștergerea intrărilor din lista de
contacte fără acordul utilizatorului.
• Premeditated Spyware – reprezintă ascultarea la distanță și identificarea locației.
• Proof of Concept – constă în malware/spyware care, de exemplu, menține activ
Bluetooth -ul fără acordul utilizatorului și astfel bateria este golită.
“Anumite malware -uri nu au cauzat niciun rău și par a fi fost doar teste de proof of
concept; oricum, au fost și cazuri de malware care au cauzat probleme neașteptate sau nedorite
precum consumu l neobișnuit de energie sau denial of service localizat, etc. Există mai multe
programe care încearcă să fure date sau servicii de pe telefoane. Un alt tip de malware este un
Spyware are poate accesa microfoane, camere și receptoare GPS built -in pentru a t ransmite date

37 către atacatori. Adware este un alt tip de malware ce utilizează canalele de comunicare existente
precum e -mail, IM, MMS, Bluetooth sau SMS pentru a transmite reclame nedorite către numere
aleatoare sau către persoane din apropiere sau în car tea de telefon a cuiva ” [26].
3.6. Reverse engineering
“Reverse Engineering este un proces de a analiza un cod sau un software existent pentru
a scruta software -ul de vulnerabilități sau erori. Reverse engineering reprezintă abilitatea de a
genera codul sursă dintr -un executabil. Această tehnică este folosită pentru a examina
funcționarea unui program sau pentru a evita mecanismele de securitate, etc. Reverse
engineering poate fi așadar declarată ca o metodă său proces de modificare a unui program
pentru a se face să se comporte într -o manieră pe care inginerul o dorește ” [26] .
Aplicația, în formatul său binar pre -compilat, este distribuită și, prin urmare, nu este
posibilă depanarea directă a codului sursă. Cu toate acestea, există dezasamblori care conve rtesc
sau inversează Daltak Bytecode în format lizibil. Binarele pentru Dalvik Virtual Machines sunt
în format. Dex. Backsmali este un dezasamblor care este folosit pentru fișierele. Dex din Dalvik
VM. Dacă programatorii doresc să modifice codul sursă și s ă îl reambaleze, se utilizează
APKtool.
Există mulți programatori care au inversat diverse aplicații Android pentru a studia
vulnerabilitățile, dacă există, și pentru a examina codul.
3.7. Atenuarea riscurilor
Există multe măsuri care pot fi integrate pentru a atenua atacurile malware pe Android.
A. Responsabilitățile dezvoltatorilor privind securitatea
Orice dezvoltator are nevoie să se concentreze pe securitatea datelor utilizatorului. “Orice
aplicație are asignat propriul UID; în orice caz, este posi bil ca orice program să ceară
Managerului de Activități (Activity Manager) să pornească o aplicație care rulează cu acel UID.
În Android, semnarea aplicațiilor este de obicei obținută prin utilizarea certificatelor self -signed.
Motivul major pentru care se insistă pe semnarea codului este pentru a permite dezvoltatorilor să
realizeze update -uri aplicațiilor lor deja existente. Diferite aplicații care sunt semnate folosind
aceeași cheie pot solicita să ruleze cu același ID deoarece sunt dezvoltate de același dezvoltator ”
[26]. Totuși, este important de notat faptul că semnarea aplicațiilor nu validează identitatea reală
a dezvoltatorului.
B. Responsabilitățile utilizatorului privind securitatea

38 Când un utilizator instalează aplicații, trebuie să le ofere perm isiunile cerute de acestea.
Deci, este extrem de important ca un utilizator să înțeleagă permisiunile solicitate de aplicații.
Există câteva aplicații precum Skype care au nevoie de acces la o gamă variată de date de pe
telefon, dar sunt și câteva aplicați i precum Wallpapers, Calendar, etc. Care au nevoie de foarte
puține permisiuni [26].
C. Instalarea unui Antivirus
Instalarea unui antivirus pe telefon, la fel ca pe o platformă desktop, va ajuta la
identificarea malware și la prevenirea utilizatorului să î l instaleze. Există câteva soluții de
antivirus pentru Android care poate pot ajuta la curățarea malware -ului și la protejarea
telefonului de acesta [26].
D. Controlul Accesului la Rețea
Este important ca companiile să controleze conexiunile la rețea deoar ece atacatorii pot
conecta un dispozitiv Android la un sistem, utilizându -l astfel că o conexiune de rețea
alternativă. Acest lucru oferă atacatorului o rută mult mai simplă pentru a trece de firewall -urile
companiei, sistemele DLP și regulile de Rutare We b.

39
Capitolul 4. Aplica ție Android pentru eviden ța pacien ților în
sistemul asigur ărilor de s ănătate
Pentru crearea unei aplicații Android pentru evidența pacienților în sistemul asigurărilor
de sănătate s -a folosit programele Android Studio și Firebase.
Android Studio este un mediu de dezvoltare (engl. software development environment,
sau integrated development environment – "mediu integrat de dezvoltare) pentru colaborarea cu
platforma Android.
Android Studio este bazat pe software -ul IntelliJ IDEA de la JetBrains, este instrumentul
oficial de dezvoltare a aplicațiilor Android. Acest mediu de dezvoltare este disponibil pentru
Windows, OS X și Linux.
Firebase este o platformă de dezvoltare pentru aplicații mobile și web. Cu Firebase, s e
poate crea rapid aplicații de înaltă calitate, se poate stabilii o bază de utilizatori implicată.
Platforma include mai multe funcții strâns legate între ele, care se pot combina. Printre acestea se
numără soluții de analiză, un backend mobil și instrume nte de dezvoltare a aplicațiilor și de
generare de venituri.
Am creat aplicația folosind Android Studio și Firebase am adăugat câteva persoane în
sistemul nou creat pentru a de monstra capabilitățile aplicației , după care am făcut mai multe
print screen -uri pentru a ilustra interfața noului program creat și pentru a evidenția conexiunile
între diferitele funcțiuni ale programului.
Toate acestea vor fi prezentate în continuare pentru a putea prezenta aplicația.

40
Figura 4.1. Interfața principală a aplicației pentru evidența pacienților în sistemul asigurărilor de
sănătate
În xml -ul prezentat în figura 4.1 am creat interfața de început a aplicației prin care
utilizatorul trebuie să se logheze sau să își creeze un cont nou pentru a avea acces la aplicație.
Accesul se face pe bază de e -mail, drept utilizator, și pe bază de parolă. În această int erfață există
și posibilitatea creării unui nou utilizator prin opțiune “Don’t have an account? Sign up”

41
Figura 4.2. Script -ul pentru butoanele de logare și înregistrare în aplicația pentru evidența
pacienților în sistemul asigurărilor de sănătate
com.example.proiect ;

import androidx.annotation. NonNull;
import androidx.appcompat.app.AppCompatActivity ;

import android.app.ProgressDialog ;
import android.content.Intent ;
import android.os.Bundle ;
import android.text.TextUtils ;
import android.view.View ;
import android.widget.Button ;
import android.widget.EditText ;
import android.widget.TextView ;
import android.widget.Toast ;

import com.google.android.gms.tasks.OnCompleteListener ;
import com.google.android.gms.tasks.Task ;
import com.google.firebase.auth.AuthR esult;
import com.google.firebase.auth.FirebaseAuth ;

public class LoginActivity extends AppCompatActivity {

EditText email,password ;
Button login;
TextView txt_signup ;

FirebaseAuth auth;

@Override
protected void onCreate (Bundle savedInstanceState) {
super.onCreate(savedInstanceState) ;
setContentView(R.layout. activity_login );
email = findViewById(R.id. email);
login = findViewById(R.id. login);
password = findViewById(R.id. password );
txt_signup = findViewById(R.id. txt_singup );

auth = FirebaseAuth. getInstance ();
login = findViewById(R.id. login);
register = findViewById(R.id. register );

login.setOnClickListener( new View.OnClickListener() {
@Override
public void onClick(View v) {
startActivity( new Intent(MainActivity. this, LoginActivity. class));
}
});

register .setOnClickListener( new View.OnClickListener() {
@Override
public void onClick(View v) {
startActivity( new Intent(MainActivity. this, RegisterActivity. class));
}
});

}
}

42
txt_signup .setOnClickListener( new View.OnClickListener() {
@Override
public void onClick(View v) {
startActivity( new Intent(LoginActivity. this ,
RegisterActivity. class));
}
});

login.setOnClickListener( new View.OnClickListener() {
@Override
public void onClick(View v) {
final ProgressDialog pd = new ProgressDialog(LoginActivity. this);
pd.setMessage( "Please wait…" );
pd.show() ;

String str_email = email.getText().toString() ;
String str_password = password .getText().toString() ;

if(TextUtils. isEmpty(str_email) || TextUtils. isEmpty(str_password))
{
Toast.makeText (LoginActivity. this, "All fields are required!" ,
Toast.LENGTH_SHOR T).show() ;
}
else
{
auth.signInWithEmailAndPassword(str_email ,
str_password).addOnCompleteListener(LoginActivity. this, new
OnCompleteListener<AuthResult>() {
@Override
public void onComplete (@NonNull Task<AuthResult> task) {
if(task.isSuccessful()){
pd.dismiss() ;
Intent intent = new Intent(LoginActivity. this,
StartActivity. class);
intent.addFlags(Intent. FLAG_ACTIVITY_NEW_TASK |
Intent.FLAG_ACTIVITY_CLEAR_TASK );
startActivity(intent) ;
finish();
} else {
pd.dismiss() ;
Toast.makeText (LoginActivity. this, "Authentification
failed!" , Toast.LENGTH_SHORT ).show() ;
}
}
});

}
}
});

}

}
Figura 4.3. Script -ul clasa unde e facut ă logarea în aplicația pentru evidența pacienților în
sistemul asigurărilor de să nătate
În figura 4.2 si 4.3 sunt prezentate modalitatea de realizare a butoanele de logare și
înregistrare în programul Android Studio.

43
Figura 4.4. Interfața pentru adăugar ea unui nou asigurat în aplicația pentru evidența pacienților în
sistemul asigurărilor de sănătate
În figură 4.4. este prezentat xml -ul pentru interfață grafică în momentul în care noi dorim
să adăugăm un nou asigurat. În partea de sus ale interfeței se trece orașul după care urmează
poza asiguratului pe care o putem lua din galeria foto sau să îi facem o poză instant, acestea fiind
urmate de câteva date ale asiguratului pentru a putea fii adăugat în baza de date.

44 package com.example.proiect ;

import androidx.annotation. NonNull;
import androidx.annotation. Nullable ;
import androidx.appcompat.app.AppCompatActivity ;

import android.app.ProgressDialog ;
import android.content.ContentResolver ;
import android.content.Intent ;
import android.net.Uri ;
import android.os.Bundle ;
import android.view.Vi ew;
import android.webkit.MimeTypeMap ;
import android.widget.Button ;
import android.widget.EditText ;
import android.widget.ImageView ;
import android.widget.Spinner ;
import android.widget.Toast ;

import com.google.android.gms.tasks.Continuation ;
import com.google.android.gms.tasks.OnCompleteListener ;
import com.google.android.gms.tasks.OnFailureListener ;
import com.google.android.gms.tasks.Task ;
import com.google.firebase.auth.FirebaseAuth ;
import com.google.firebase.database.DatabaseReference ;
import com.google.firebase.database.FirebaseDatabase ;
import com.google.firebase.storage.FirebaseStorage ;
import com.google.firebase.storage.StorageReference ;
import com.google.firebase.storage.StorageTask ;
import com.theartofdev.edmodo.cropper.CropImage ;

import java.util.HashMap ;

public class AddActivity extends AppCompatActivity {

Button add;

Uri imageUri ;
String myUrl = "";
StorageTask uploadTask ;
StorageReference storageReference ;

ImageView image_added ;
EditText varsta;
EditText name;
EditText phone;
EditText cnp;
Spinner spinner;

@Override
protected void onCreate (Bundle savedInstanceState) {
super.onCreate(savedInstanceState) ;
setContentV iew(R.layout. activity_add );

add = findViewById(R.id. button_add );
image_added = findViewById(R.id. image_added );
varsta = findViewById(R.id. varsta);
name = findViewById(R.id. name);
phone = findViewById(R.id. phone);
cnp = findViewById(R.id. cnp);
spinner = findViewById(R.id. spinner);

45
storageReference = FirebaseStorage. getInstance ().getReference( "asigurati" );

add.setOnClickListener( new View.OnClickListener() {
@Override
public void onClick(View view) {
uploadImage() ;
}
});

CropImage. activity ().start(AddActivity. this);

}

private String getFileextension (Uri uri)
{
ContentRe solver contentResolver = getContentResolver() ;
MimeTypeMap mime = MimeTypeMap. getSingleton ();
return mime.getExtensionFromMimeType(contentResolver.getType(uri)) ;
}

private void uploadImage ()
{
final ProgressDialog progressDialog = new ProgressDialog( this);
progressDialog.setMessage( "Se posteaza" );
progressDialog.show() ;

if (imageUri != null)
{
final StorageReference filereference =
storageReference .child(Sy stem.currentTimeMillis ()
+"."+ getFileextension( imageUri ));

uploadTask = filereference.putFile( imageUri );
uploadTask .continueWithTask( new Continuation() {
@Override
public Object then(@NonNull Task task) throws Exception {
if(!task.isSuccessful())
{
throw task.getException() ;
}

return filereference .getDownloadUrl() ;
}
}).addOnCompleteListener( new OnCompleteListener<Uri>() {
@Override
public void onComplete (@NonNull Task<Uri> task) {
if(task.isSuccessful())
{
Uri downloadUri = task.getResult() ;
myUrl = downloadUri.toString() ;

DatabaseReference reference =
FirebaseDatabase. getInstance ().getReference( "asigurati" ).child( spinner.getSelectedIte
m().toString()) ;

String postid = reference.push().getKey() ;

HashMap<String , Object> hashMap = new HashMap<>() ;
hashMap.put( "postid" , postid);
hashMap.put( "postimage", myUrl);

46 hashMap.put( "name", name.getText().toString()) ;
hashMap.put( "varsta" , varsta.getText().toString()) ;
hashMap.put( "phone", phone.getText().toString()) ;
hashMap.put( "cnp", cnp.getText().toString()) ;
hashMap.put( "publisher" ,
FirebaseAuth. getInstance ().getCurrentUser().getUid()) ;

reference.child(postid).setValue(hashMap) ;

progressDialog .dismiss() ;

startActivity( new Intent(AddActivity. this,
StartActivity. class));
finish() ;
}
else
{
Toast.makeText (AddActivity. this, "Failed!" ,
Toast.LENGTH_SHORT ).show() ;
}
}
}).addOnFailureListener( new OnFailureListener() {
@Override
public void onFailure (@NonNull Exception e) {
Toast.makeText (AddActivity. this, ""+e.getMessage() ,
Toast.LENGTH_SHORT ).show() ;
}
});
}
else
{
Toast.makeText (this , "No Image Selected!" , Toast.LENGTH_SHORT ).show() ;
}
}

@Override
protected void onActivityResult (int requestCode , int resultCode , @Nullable Intent
data) {
super.onActivityResult(requestCode , resultCode , data);

if(requestCode == CropImage. CROP_IMAGE_ACTIVITY_REQUEST_CODE && resultCode ==
RESULT_OK )
{
CropImage.ActivityResult result = CropImage. getActivityResult (data);
imageUri = result.getUri() ;

image_added .setImageURI( imageUri );
}
else
{
Toast.makeText (this, "Something gone wrong!" , Toast.LENGTH_SHORT ).show() ;
startActivity( new Intent(AddActivity. this, StartActivity. class));
finish() ;
}
}

}
Figura 4.5. Script -ul clasei unde e făcută adăugarea de asigurat pentru evidența pacienților în
sistemul asigurărilor de sănătate

47 În figura 4.5 este prezentată modalitatea de realizare a interfeței pentru adăugarea unui
asigurat nou în programul A ndroid Studio.

Figura 4.6. Interfața pentru adăugar ea unui nou asigurat
În această parte a aplicației putem elimina un asigurat vizualizând poza acestuia și
apăsând butonul de “ștergere asigurat”.

48
Figura 4.7. Interfaț a meniului principal a aplicație i pentru evidența pacienților în sistemul
asigurărilor de sănătate
Acesta este meniul principal al aplicației unde putem vedea asigurații în funcție de
orașele unde sunt repartizați. De asemenea este un buton în vârful paginii “lista asigurați”, care
ne af ișează toți asigurații înregistrați în aplicație.

49
Figura 4.8. Interfaț ă listă asigurați a aplicației pentru evidența pacienților în sistemul asigurărilor
de sănătate
În figura 4.8. este prezentată opțiunea pentru lista asigurați, este prezentat modul de
afișare când se apasă pe butonul “lista asigurați”. Derulând în jos se pot observa toți asigurații
adăugați în sistem.

50
Figura 4.9. Interfața sistem eviden ță asigurați a aplicației pentru evidența pacienților în sistemul
asigurărilor de sănătate
Pentru a stoca toate datele într -o bază de date am folosit “Firebase”, unde îmi sunt
gestionați toți asigurații în funcție de orașe. În momentul în care se adaugă un asigurat nou în
aplicați e, automat va apărea și în baza de date, la fel funcționând și pentru ștergerea unui
asigurat.
Datele prezentate pentru fiecare asigurat în parte sunt:
• CNP
• Nume
• Telefon
• Vârsta

51
Figura 4.10. Interfața eviden ță useri pentru aplicația pentru evidența pac ienților în sistemul
asigurărilor de sănătate
În figură 4.10 este prezentată eviden ța datelor de conectare a asiguraților din sistem.
Aceasta este partea de autentificare unde avem lista user -ilor care și -au creat un cont de aplicație,
noi putând adăuga u seri noi sau să schimbăm parola.
Informațiile gestionate sunt:
• User / e -mail
• Când a fost creat contul
• Ultima accesare

52
Figura 4.11. Interfața posibilități de autentificare a asiguraților pentru aplicația evidența
pacienților în sistemul asigurărilor de sănătate
În figura 4.11 sunt prezentate modalitățile de logare în aplicație. Acestea sunt:
• Email/password
• Număr telefon
• Prin Google
• Prin Facebook
• Prin Twitter
• Prin Play Games

53
Figura 4.12. Em ail de verifi care pentru aplicația evidența pacienților în sistemul asigurărilor de
sănătate
În momentul care îți creezi un cont pe aplicație , un email de verificare se va trimite
automat pentru validarea mailului care s -a folosit pentru crearea contului.

54
Figura 4. 13. Email de resetarea parolei pentru aplicația evidența pacienților în sistemul
asigurărilor de sănătate
După același principiu funcționează și resetarea parolei în cazul în care un u ser-ul își uit ă
parola. Acesta v -a primi un link prin mail prin care își poate adăuga o nouă parolă.

55 Concluzii
Pentru o lungă perioadă de timp, sistemele securizate au fost sinonime cu sistemele
închise, dar ecosistemul mobil se transformă acum de la platforme izolate închise spre platforme
deschise care promovează inovația și permit interoperabilitatea cu încredere. Android, fiind mai
accesibilă, este mai securizată. Sistemul de securitate Android este construit pentru a -și proteja
utilizatorii într -un ecosistem complex.
Întărirea securității pentru toți utilizatorii de dispozitive Android include o combinație de
funcții de securitate încorporate în platformă (cum ar fi sandbox -urile aplicațiilor) și protecții
bazate pe servicii Google (cum ar fi Google Play și Verificarea aplicațiilor). În spatele încercă rii
de a proteja împotriva aplicațiilor potențial dăunătoare este o vastă cunoaștere sistemică a
aplicațiilor Android acumulate pe mai mulți ani, începând cu debutul Android. Pentru astfel de
analiză se folosește o combinație de elemente statice, dinamice și analiza relațiilor.
Protejarea datelor personale a siguraților c are vor utiliza aplicația creat ă va fi de
importanță maximă, deoarece aceast ă aplicație conține informații sensibile ale utilizatorilor.
Unul din principalele avantaje ale folosirii platfo rmei Android îl constituie numărul mare
de informații, resurse, mostre de cod și numărul mare de dezvoltatori cu experiență dispuși să
ajute atunci când întâmpini o problemă. Dezvoltarea de noi aplicații nu necesită achiziționarea
unei licențe care costă, dezvoltarea fiind gratuită și la îndemâna oricărei persoane care dorește să
încerce.
Contribuția personală constă în realizarea unei aplicații pe platformă Android ce permite
utilizarea funcționalităților oferite de sistemul de eviden ță a pacienților în si stemul asigurărilor
de sănătate pe telefonul mobil. Aceasta constă în realizarea unei interfețe grafice, sistemul de
înregistrare a pacienților, realizarea unei variante compatibile cu platforma Android a
protocolului de conectare la server și crearea unei baze de date pentru gestionarea pacienților.

56 Bibliografie
1. Alexandru, Cosmin informatician , Crearea paginilor WEB cu HTML , Editura
Delta Cart Educational , 2011 ;
2. Bacivarov, Angelica , Programare Web , Editura Matrix Rom , 2016 ;
3. Beaird, Jason , The principles of beautiful web design , Editura SitePoint , 2010 ;
4. Brokken, Frank , C++ Annotations , University of Groningen , 2010
5. Bucata, Victor , Internet și baze de date , Editura Printech , 2016
6. Bucur, Cristian , Achiziția și analiza datelor web pentru inteligența afacerilor ,
Editura Printech , 2016 ;
7. Bușcă, Laura , Crearea paginilor web [Resursă electronică] , Editura Sfântul
Ierarh Nicolae , 2015 ;
8. Chisholm, Wendy, Universal design for Web applications , Editura O’Reilly,
2009;
9. Crețu, Liviu Gabriel , Introduce re în programare , Editura Tehnopress , 2010 ;
10. Drulă, Georgeta , Media interactivă , Editura C.H. Beck , 2014 ;
11. Ene, Alexandru , Programare pentru web , Editura Universității din Pitești , 2015 ;
12. Enyedi, Szilárd , Programare multimedia și design de pagini web , Editura
Risoprint , 2014
13. Filip, Ioan automatic, Programare Web , Editura Conspress , 2013 ;
14. Ionuț, Silviu Tudor , Design și programare Web , Editura Eurocor , 2009 ;
15. Josuttis, Nicolai M. , The C++ Standard Library, A Tutorial and Reference
(Second ed.) , Addison -Wesley, 2012
16. Miloșescu, Mariana , SGBD – sisteme de gestiune a bazelor de date , Editura
Didactică și Pedagogică , 2016
17. Mocean, Loredana , Baze de date , Editura Risoprint , 2017 ;
18. Oancea, Romana , Informatică aplicată , Editura Academiei Forțelor Terestre
"Nicolae Bă lcescu" , 2010 ;
19. Popovici, Florentina, Data -driven models in storage system design , University of
Wisconsin Press, 2007;
20. Rusu, Ioan , Baze de date , Editura Matrix Rom , 2016
21. Sanislav, Teodora , Baze de date relaționale și nerelaționale , Editura U.T. Press ,
2015 ;
22. Stroustrup, Bjarne , Programming: Principles and Practice Using C++ (Second
ed.), Addison -Wesley , 2014 ;

57 23. Ungureanu, Delia , Programare WEB [Resursă electronică] , Editura Universității
Transilvania din Brașov , 2014 ;
24. Vaida, Mircea -Florin , Programare orien tată pe obiecte și Programare Web în
C/C++ , Editura Casa Cărții de Știință , 2011 ;
25. Watrall, Ethan , Head first web design , Editura O’Reilly , 2009 ;
26. Android security white paper, 2016, Google
27. Casa Națională de Asigurări de Sănătate din România, Specificații de interfațare
cu SIUI+PE+CEAS pentru aplicațiile de raportare ale furnizorilor de servicii
medicale și farmaceutice, 2018.
28. www.microsoft.com/net
29. www.gotdotnet.com
30. www.dotnetjunkies.com
31. www.dotnetextreme.com
32. www.devcity.net/net
33. www.dotnet247.com
34. www.dotnetdan.com