Specializarea : Informatică [627005]

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

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
Capitolu l 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. Compo nente 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 me dico-farmaceutice.
La nivelul CNAS se pot accesa toate datele din baza de date centralizată: atât datele
proprii, cât și cele 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 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
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 p revă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ă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 (CA S)
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ță informatizată și de au tomatizare a prescrierii și
eliberării medicamentelor compensate și gratuite ”[27].
La nivelul CNAS se pot accesa toate datele din 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 asigur atului, 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 [27].
Pentru furnizorii de servicii medico -farmaceutice sistemul preve de 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 cate gorii de furnizori cu care sistemul (SIUI)
operează schimburi de date [27]:
• furnizorii de servicii medicale furnizorii de dispozitive medicale
• furnizorii de medicamente și servicii farmaceutice
Pentru toate tipurile de furnizori există aplicații informatic e prin care aceștia pot raporta
către nivelul central serviciile prestate sau produsele furnizate și pot prelua de la nivelul central
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 servicii medicale și farmaceutice se transferă, în format electronic
în SIUI. Transferul poate fi făcut online, prin comunicație elec tronică 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 pr elucrării acestor raportări la nivel CJAS, prin transmiterea erorilor
detectate către fiecare furnizor de servicii medicale și farmaceutice ”[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 pentru sistemul informatic
integrat de la nivel județean. Aceste informații pot proveni fie, pe un flux informațional
prestabilit, prin transfer d e 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 ju dețean, acesta fiind nivelul
în care informațiile sunt prelucrate, iar în urma prelucrării vor fi obținute datele de 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 informatic 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 nec esare 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 s ervicii 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 Informati c Unic Integrat al Asigurărilor de Sănătate din România, și pot fi denumite
generic “cataloage” sau “nomenclatoare”. Aceste informații sunt transmise prin intermediul unui
flux informațional către nivelul CJAS care, la rândul său, prin intermediul altui fl ux
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 C NAS 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
• farmaceutic e 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 angajatorii, 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ționalitate
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 farmaceutice 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 serviciil or 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 prelu cră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 rezultatului
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 medica le ș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ă raportez e 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 acestor int erfeț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 servicii 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 finală, 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, reducân d 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 autorizarea 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ți uni 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 pentru
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 Sociale – 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ă cripto grafia
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 integrează certificatele digi tale, 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, ba ze 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. Marca
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ă de scrie
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 proprietarului.
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 asimetrice, cheia publică def ineș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
Autorităț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 identificarea 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 datele și motivele revocări i 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 destinatarului împotriva falsif ică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 p ermite
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, aplicațiile nu trebuie să c onsulte 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 on line 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;
• utilizatorii sistemului vor benefi cia 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 suport 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ă p oată: 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 oper atorii 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 dig itale 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
raport are ș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 folosește
certificatul pentru autentificarea și autorizarea cererilor online căt re 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, accelerator SSL și load -balancer, în același timp realizând și verificarea
certificate lor 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 integrității și valabilității certificatului, acceleratorul SSL transmite
mai depar te 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 protocolul OCSP
către serviciul pus la dispoziție de STS. Acest serviciu veri fică autenticitatea certificatului prin
interogarea serviciilor similare ale autorităților de certificare publice cu care STS are protocoale
de comunicare [27].
Serviciul de Telecomunicaț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 acestor
autorități. Această componentă trebuie să respecte, la rândul ei, caracte risticile 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 asoc iat 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 sistemu lui 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 de 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: Certificatul este valid, iar utilizatorul este autorizat să acceseze sistemul
online, d ar 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țiilor, 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 resursele 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 serviciul Web să poată fi efectuate direct.
1.3.2. Semnătura digitală
Semnăt ura 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 digitală 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 p ersoană 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 certificare, legal constituit, numit
autoritate de certificare.
“Pentru a gar anta 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 sistem. Prin semnarea electronică a fișierelor de raportare se creează p remisele
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 raportare ș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ă 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 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ă fi e 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șierul 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 aut entificare ș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 dig ital 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 sau 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 col ecț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 mecan isme 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, sistem ul 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 informaț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 recen te 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 poate fi împărtășită
de mulți utilizatori, ast fel 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 utilizatorulu i.
• 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 utilizatorului sau programului de aplicație
de a defini li mitele 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ă r estaura 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ă de mai mulți
utilizatori, doi sau mai mulți utili zatori 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 trebuie protejate împotriva utilizării
necorespunzătoa re 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 accesează adesea o bază de date
cu ajutorul unor termi nale 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 varietate de verificări de editare și
constrângeri d e 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 structură complexă care este utilizată pentru gestion area, 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 in terrelaț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. Persoanele care introduc date în baza de date.
4. Persoa nele 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 softwar e-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 care 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 de 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ă pentru a utiliza această putere
disponibilă. Tipurile de struc turi 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 f olosim 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 simplificate ale evenimentelor sau
condițiilor din lumea reală. D acă 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. „Modelele 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 informaț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 cerințele de raportare a informațiilor cat re 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 v izualiză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, indif erent 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 Vizualizarea 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 s istem 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 bazelor 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 abstractizare, 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ă unul
preocupat de modul în care datele sunt s tocate 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 conceptual / logic: este un „nivel de indirecți e” î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. Ace st 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 raspunzat or 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 date. În ciuda
utilizării unor structuri mai simple la nivel logic, rămâne o oarecare complexit ate, 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ști 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 individuale ale utilizatorului, nivelul
conceptual poate fi gândit ca definind o vedere a comuni tăț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țiuni a bazei de date și va exista o singură „viziune conceptuală”, constând

22 dintr -o reprezentar e 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ă efectiv.
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 s ubscheme.
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 datelor. Există
două niveluri de independență a datelor, adică [22].
a. Indepe ndenț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 performanț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 logică 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 totale adică
în legătură cu obiectele și operațiunile bazei de date. DSL es te 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 b azei 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 spec ial 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 sistemul de baze de date.
Structura de stocare și metodele de acces utiliza te 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): este 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 nivelurile externe și conceptuale ale sistemului; și
ii. între nivelurile conceptuale și cel e 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 exprimate (prin intermediul DML) în termeni de
înregistrări externe și trebui e 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 hardware real, adică în operații pe înregistrări fizice. Componenta responsabi lă 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 interfață stocată.
Interfața stocată corespunde astfel nivelului intern, la f el 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 un ui 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 stocate, dacă este cazul, pe care sunt secvențiate și (d) câmpurile
stocate, da că 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 proiectarea bazelor de date
Prima fază : Scopul general al studiului inițial al baze i 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 aplicare și limitelor.
A doua fază : A doua fază se concentrează pe proiectarea mo delului 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 DBM S
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. Proiectarea 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ă aplicațiile bazei de date analizate
în faza 1 și produce specificații la niv el î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 car e 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 funcț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 bazei 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 ur mare, 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 datel or 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 d uc 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 suportate de modelul bazei de date [22].
Verificarea necesită ca modelul să p oată 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țiunilor,
interogărilor și rapoartelor.
b. Căile de acces, securitatea și cont rolul 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 u nei
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 la 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 final 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) Portabilitate ș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 departe). 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 selectat. În această etapă, designu l 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 necesare.
IV. Proiectare fizică: E tapa 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 s tocare 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 în ainte 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 inst rumentele 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 mobile ” [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ă a le 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 stivă după kernel este nivel ul 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 f urnizorii 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ă diferite 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 n ivel, 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 optimizată 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 gestionar ea 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 folosit 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 cre ate 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
invocate 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 co mponente 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 default al utilizatorulu i 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 c reate 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 caracteristicilor dispozitivu lui î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, cum ar fi că Magazi nul 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 aplicație simplă An droid 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 dispozitiv ului,
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/re s
/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ă permisiuni
care nu prezintă un risc prea mare pentr u 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 putea 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 (niv el 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,
astfel î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ă
acord e 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 utilizatorul actualizează aplicația. După ce utili zatorul
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 lu cru 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ă n u 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ă define ască ș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
programului:
– În momentul unei apelări în sistem, pe ntru 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 controla cine poate recepționa sau cine
poate tri mite 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 m anifestul 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. Dacă
valoarea este mai mică decât ver siunea î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 e ste 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 suplimentare, chiar dacă este posibil ca a plicaț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
verifica 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 instal a 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 fra gment 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 d e 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 a plicaț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
perm isiune 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 utiliz ator
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 permisiune a 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 targetSdkVersion a aplicației
este de 23 sau mai mult, următorul compor tament 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 permisiuni î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 dial og 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ă” a fiș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 normale 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 aplicația, și nu permisiunile individuale.
3.3. Gestionarea cred enț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țialelor î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 autentificator solicită credențialele de la utilizator, le valide ază 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 componentă specifică
(autentificator) care să se autentific e 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 f undalul 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 fi 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 aplicaț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 mesajelor, 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 argument al acesteia.
“O transformare este un șir care specifică numel e 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 transformarea ca:
AES/CBC/PKCS5Padding. Numai partea de algoritm este obliga torie. 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, Java ș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 EC B.
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 posibil 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 sau acces la
distanță la un sistem în timpul în ca re 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 atacurilor 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 bateri a 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 consumul neobișnuit de energie sau denial of service l ocalizat, 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 transmite date

37 către atacatori. Adware este un a lt 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 cartea de telefon a cuiva ” [26].
3.6. Reverse engineer ing
“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 folos ită 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 ingin erul 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 convertesc
sau inversează Daltak Bytecode în format lizibi l. 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 posibil ca orice program să ceară
Managerului de Activități (Activ ity 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 dezvoltator ilor 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 permisiunile 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ții 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 deoarece 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 Web.

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 de zvoltare 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, se
poate crea rapid aplicații de înaltă calitate, se poate stabil ii 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 instrumente 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 evi denț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ă interfață exi stă
ș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.pr oiect;

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.AuthResult ;
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ției 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 pagin ii “lista asigurați”, care
ne afiș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 asi guraț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ție, 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 pacienț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 pr omovează 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 ut ilizatorii 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ări i
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 platform ei 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ă, de zvoltarea 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 sist emul 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 b aze 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 , Introducere în prog ramare , 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 orientată p e 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 inter faț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