MINISTERUL EDUCAIEI AL REPUBLICII MOLDOVAUNIVERSITATEA TEHNIC A MOLDOVEIFACULTATEA CALCULATOARE, INFORMATIC I MICROELECTONICCATEDRA AUTOMATIC I TEHNOLOGII INFORMAIONALE

Proiect de an laAnaliza, Modelarea Sistemelor Informaionale

Tema: Analiza i modelarea sistemului de securitate integru al oficiului administrativ

A elaborat: Stolear Verginia studenta gr. TI-111 f/r

A verificat : lector sup. Melnic Radu

Chiinu 2014

CUPRINS

INTRODUCERE21.DOCUMENTE DE REFERIN31. 1. Indicaii teoretice31.2. Specificarea cerinelor utilizatorului.62. SUMARUL ACTIVITILOR NECESARE PENTRU REALIZAREA PRODUSULUI.72.1. Cerine i restricii privind sistemul i produsul informatic.72.2. Cerine i restricii privind documentaia proiectului.73. PLANIFICAREA GENERAL A ACTIVITILOR DE REALIZARE A PRODUSULUI INFORMATIC.73.1. Descriere generala a procesului de realizare a produsului.73.1.1 Diagrame a cazurilor de utilizare83.1.2 Diagrame de interaciune.123.1.3. Diagrame de clase193.1.4. Diagramele de componente223.1.5. Diagrama de amplasare25CONCLUZIE26BIBLIOGRAFIE26

INTRODUCERE

Lucrarea de fa va prezenta rezultatul analizei, modelrii i proiectrii unui sistem informatic care realizeaz securitatea att la nivel de acces a persoanelor n cadrul sediului, ct i de securitatea a informaiei n cadrul reelei interne a oficiului administrativ. Executarea acestor 3 etape a ciclului de via a sistemului se realizeaz utiliznd metodologia Obiect Orientat, n care drept instrument CASE s-a utilizat Enterprise Architect.Sistemul de securitate respectiv, dup cum s-a menionat, realizeaz securitatea la nivel de acces a persoanelor, precum i securitatea circulaiei informaiei n cadrul reelei de calculatoare. La nivelul accesului persoanelor se prevede nregistrarea acestora la Registratur care introduce datele persoanelor n baza de date a oficiului, n rezultat se elibereaz un permis care permite circulaia acestora n cadrul sediului oficiului. Acest permis este utilizat pentru deblocarea porilor rotative/ ui n limita permis de acesta. n cazul n care permisul este eliberat unui funcionar, pe lng funciile expuse mai sus, mai este prevzut alocarea unui PIN code necesar pentru autentificarea n reeaua de calculatoare, code atribuit de administratorul sistemului de calcul. n afara nregistrrii persoanelor, acestea vor fi monitorizate de ctre paza oficiului care va urmri deplasarea acestora (utiliznd camere video, unite la calculator cu posibilitatea identificrii persoanelor) cu eventuala intervenie. La nivel informaional securitatea se va manifesta prin permiterea accesrii unui calculator doar n baza identificrii prin PIN code si parol la unul din profile-lul specificat cu drepturi de ctre administratorul sistemului de calcul, precum i la nivelul circulaiei informaiei prin reea utiliznd subreele securizate ntre componentele cheie ale sistemului de calcul (Detalii diagrama de plasamente), precum i utiliznd subreele publice cu transfer codificat a informaiei. Activitatea pazei i a administratorului este monitorizat de ctre Administratorul sistemului.

1. DOCUMENTE DE REFERIN

1. 1. Indicaii teoretice

Unified Modeling Language(prescurtatUML) este un limbaj standard pentru descrierea demodeleispecificaiipentrusoftware. UML a fost la baz dezvoltat pentru reprezentarea complexitii programelor orientate pe obiect, al cror fundament este structurarea programelor pe clase, i instanele acestora (numite i obiecte). Cu toate acestea, datorit eficienei i claritii n reprezentarea unor elemente abstracte, UML este utilizat dincolo de domeniul IT. Aa se face c exist aplicaii ale UML-ului pentru management de proiecte, pentrubusiness Process Design.Dei destinate iniial pentru documentaia de proiectare orientate-obiect, Unified Modeling Language (UML) a fost extins pentru a cuprinde documentaia de proiectare orientate pe proces, iar acum combin tehnici demodelare a datelor(entitate diagrame relaie),modelare de afaceri(fluxuri de lucru),modelare obiect, i modelare componente.Acesta poate fi utilizat cu toate procesele, de-a lungulciclului de via de dezvoltare de software, i utiliznd diferite tehnologii de implementare. Unified Modeling Language (UML) ofera o modalitate standard de a vizualiza planuri arhitecturale un sistem, inclusiv elemente cum ar fi: Activiti actori proceselor de afaceri de baze de datescheme (logice)componente limbaj de programaredeclaraii reutilizabilecomponente software. Modelele UML pot fi transformate n mod automat la alte reprezentri (de exemplu Java) prin intermediulunorlimbi de transformare QVT asemntoare.UML esteextensibil, cu dou mecanisme de personalizare:profileistereotipuri.

Diagramele UMLDiagrame structuraleDiagramele structurale subliniaz lucrurile care trebuie s fie prezente n sistemul modelat. Deoarece diagramele de structur reprezint structura, acestea sunt larg utilizate n documentarea arhitecturii sistemelor software. Diagrama de clas: descrie structura unui sistem artnd clase ale sistemului, atributele lor, proprietile i relaiile dintre clase. Diagrama de componente: descrie modul n care un sistem software este mprit n componente i arat dependena ntre aceste componente.Diagrame comportamentaleDiagrame de comportament subliniaz ceea ce trebuie s se ntmple n sistemul modelat. Deoarece diagramele de comportament ilustreaz comportarea unui sistem, care sunt utilizate pe scar larg pentru a descrie funcionarea sistemelor software. Diagrama de activitate: descrie pas cu pas fluxurile operaionale ale componentelor de afaceri ntr-un sistem. O diagram de activitate prezint fluxul de ansamblu a controlului. Diagrama de stare: descrie starea i tranziiile de stare ale sistemului. Diagrama cazurilor de utilizare: descrie funcionalitatea oferit de un sistem n ceea ce privete actorii, obiectivele lor reprezentate ca cazuri de utilizare, precum i orice dependene dintre aceste cazuri de utilizare.Diagrame de interaciuneDiagrame de interaciune, un subset de diagrame de componente, subliniaz fluxul de control i date ntre lucrurile din sistemul modelat: Diagrama de comunicare: arat interaciunile dintre obiecte sau pri n ceea ce privete mesajele ordonate. Ele reprezint o combinaie de informaii luate din clasa de ordine i diagrama caz utilizare care descriu att structura static i comportamentul dinamic al unui sistem. Diagrama de secven: arat modul n care obiectele comunic ntre ele n ceea ce privete o serie de mesaje. Indic, de asemenea, durata de via a obiectelor n raport cu aceste mesaje.

1.2. Specificarea cerinelor utilizatorului.

Utilizatorii sistemului integru de securitate dup cum se poate observa sunt: Registratura, Paza, Administratorul sistemului de calcul, Administratorul sistemului, precum i funcionarii/ vizitatorii. Utilizatorii din cadrul Registraturii necesit o interfa n care vor introduce datele despre persoane, cu ulterioara salvare n baza de date, precum i validarea permisului. Utilizatorii pazei vor avea nevoie de o interfa de verificare a identitii persoanei n baza permisului de acces, precum i controlul existenei substanelor i obiectelor interzise. De altfel vor avea nevoie de o aplicaie de urmrire a camerelor video, cu posibilitatea nregistrrii i eventual recunoaterea persoanelor. Pentru Administratorul sistemului e necesar o interfa care ar putea monitoriza n timp real celorlalte subsisteme. Pentru Administratorul sistemului de calcul sunt prevzute urmtoarele cerine: posibilitatea adugrii crerii/modificrii/tergerii unui utilizator a reelei de calculatoare, cu specificarea drepturilor de acces la datele din reea, urmrirea traficului n reea, configurarea i ntreinerea bazei de date. Vizitatorii simpli vor utiliza sistemul doar prin posibilitatea de autentificare, cu permisiunea de deplasare. Funcionarii n calitate de utilizatori a calculatoarelor din reea vor avea nevoie de interfaa pentru intrarea n sistem pentru nceperea unei sesiuni de lucru, care va consta n introducerea permisului ntr-un dispozitiv de citire, cu ulterioara introducere a parolei pentru autentificare n reea. n afara de aceasta funcionarii mai au nevoie de programe care asigur transmiterea securizat datelor n reea. (Cerinele ctre sistem vor fi detaliate n diagramele Use-case)

2. SUMARUL ACTIVITILOR NECESARE PENTRU REALIZAREA PRODUSULUI.

2.1. Cerine i restricii privind sistemul i produsul informatic.

Sistemul de securitate respectiv necesit utilizarea unor calculatoare care pot susine necesitile ctre sistemul de calcul: sistemul de operare cu arhitectura de tip client-server, sistemul de gestiune a bazei de date de tip client-server (cu restricionarea accesului fizic la serverul bazei de date), cablu de reea de capacitate mare de transmitere a datelor. 2.2. Cerine i restricii privind documentaia proiectului.

Documentaia pentru utilizarea sistemului de securitate va fi distribuit doar persoanelor competente, cu drepturile i obligaiunile acordate. Documentaia n linii generale va conine informaie privitor la modul de funcionare a fiecrei din aplicaii corespunztoare utilizatorilor. Spre exemplu Administratorului sistemului de calcul i vor fi prezentate informaii privitor la tipul sistemului de operare a fiecrui calculator din reea, configurarea acestora pentru cerinele de securitate respective, modalitatea de transfer a datelor i controlul traficului n reea.3. PLANIFICAREA GENERAL A ACTIVITILOR DE REALIZARE A PRODUSULUI INFORMATIC.

3.1. Descriere generala a procesului de realizare a produsului. n elaborarea acestui sistem integru de securitate am apelat la metodologia Obiect Orientat care permite crearea obiectelor urmnd etapele de elaborare utiliznd principiile OO (motenirea, ncapsularea, polimorfismul) care ulterior pot fi utilizate n crearea aplicaiilor. Avantajul acestei metodologii (fa de cele anterioare acesteia care se concentrau asupra datelor i a funciilor ndeplinite de sistem) const n utilizarea paradigmei obiect orientat care realizeaz o serie de modele, fiecare reprezentnd una din viziunile asupra sistemului care interacioneaz ntre ele, iar luate la un loc reprezint ntregul sistem. Operaiile asupra datelor, precum i datele sunt ncapsulate n interiorul unui obiect care poate fi utilizat ulterior.

3.1.1 Diagrame a cazurilor de utilizarePentru nceput realizm diagrama cazurilor de utilizare n baza cerinelor ctre sistem (determinate n 2.1) Dup cum se vede din Figura 1 determinm urmtorii actori cu cazurile de utilizare corespunztoare fiecruia. Registratura nregistreaz persoane; Paza Monitorizare deplasare/acces persoane, monitorizare birouri, Administratorul sistemului de calcul Monitorizeaz sistemul de calcul, i respectiv Administratorul de sistem Monitorizeaz sistemul, iar Persoane monitorizate identificarea n sistem. n continuare aceast diagram va fi detaliat de alte diagrame a cazurilor de utilizare (necesar pentru a nu ncrca diagrama i pentru a fi uor de analizat).

Figura 1 - Diagrama cazurilor de utilizare ale sistemuluin diagrama dat sunt prezentai actorii principali a sistemului de securitate:Administratorul sistemului ce are funcia de a monitoriza sistemul.Administratorul sistemului de calcul ce are ca rol de a monitoriza sistemul de calcul.Paza are funciile de a monitoriza birourile, deplasarea sau accesul persoanelor.Registratura are rolul de a inregistra toate persoanele care intr n ntreprindere.Iar persoanele monitorizate se identific n sistem cu ajutorul permiselor acordate de registratur.

Figura 2 - Diagrama cazurilor de utilizare a sistemului de calculAnaliznd aceast diagram vedem rolurile unui administrator a unui sistem de calcul care cuprinde administrarea serverului central, precum si administrarea bazei de date. n continuare detaliem cazul de utilizare Administrarea_serverului_central:

Figura 3 Cazul de utilizare Administrare_server_centralDin cte observm acesta la rndul su conine nc 3 cazuri de utilizare (determinate de relaia ) crearea/modificarea/tergerea unui nou utilizator, monitorizarea traficului reelei, securizarea transferului de date. Cellalt caz de utilizare: Administrare Baz de date: este prezentat n figura 4 care cuprinde crearea viziunilor i a drepturilor de acces la baza de date:

Figura 4 Cazul de utilizare Administreaz Baz de daten continuare vom prezenta cellalt subsistem a sistemului de securitate.

Figura 5 Cazul de utilizare nregistrare persoanen cazul dat determinm 2 roluri ale Registraturii nregistrarea persoanelor i eliberarea permiselor, care la rndul lor pot fi descompuse n primirea documentelor de la persoane cu ulterioara nscriere a datelor n baza de date, respectiv nregistrarea permisului. n cazul diagramei 5 Persoanele monitorizate reprezint o abstractizare a actorilor vizitator i angajai, ultimul fiind o abstractizare a funcionarilor i a serviciului ntreinere. (Figura 6), prin mecanismul de motenire.

Figura 6 Abstractizarea Vizitatori, Angajati

Figura 7 Cazuri de utilizare PazCazul de utilizare Paz determinm urmtoarele cazuri de utilizare urmrete camere video pentru Gardieni, i urmrete acces persoane, verifica arme/ substane interzise de ctre purttorul de badge. Astfel aceste 2 persoane asigur securitatea persoanelor ce se afl n ntreprindere, att a vizitatorilor ct i a angajailor. n cazul n care vizitatorii nu respect condiiile de acces, purttorul de badge are dreptul de a ruga persoana s paraseasc cladirea cu ntoarcerea permisului eliberat.

3.1.2 Diagrame de interaciune.

Ca rezultat a celor expuse mai sus conchidem urmtoarele subsisteme: Centrul de administrare a sistemului, Monitoring personal, Monitoring sistem de calcul. n continuare vom grupa aceste subsisteme sub forma unor pachete (reprezentare n UML):

Figura 8 Subsistemele sub form de pachetePe parcursul lucrrii date s-a ndreptat atenia asupra ultimilor dou (datorat concentrrii rolurilor n aceste pachete).Chiar din analiza figurii 1 se determin componentele grupate n pachetul Monitoring personal care formeaz 2 subpachete: Paza i Registratura.Pentru primul subpachet se determin urmtoarea diagram de secven care realizeaz cazul de utilizare din figura 7 Urmrete acces persoane:

Figura 9 Diagrama de secven Acces_PersoaneAici deosebim urmtorii actori : persoane monitorizate i baza de date, iar obiectele de interaciune poart rotativ i cititor permis. n diagrama respectiv (ca i n celelalte de tipul acesta) este prezentat schimbul de mesaje (succesiunea lor n timp) care urmeaz cu executarea de proceduri de ctre recepioneri. O alternativ a acestui tip de diagrame este diagrama de colaborare care prezint doar fluxul de mesaje ntre prile ce interacioneaz.

Figura 10 Diagrama de secven nregistrare persoane

Figura 11 - Diagrama secvenelor Restituire permis

Not: de observat c obiectul permis n figura 10 apare ca urmare a apelului procedurii Activeaz_permis, iar apoi n tot acelai obiect este distrus (n figura 11) prin apelul procedurii Dezactiveaz_permis. Continum cu prezentarea strilor i a aciunilor obiectului Permis n diagrama de Stare/Activitate utilizare permis. n dreptunghiurile cu colurile rotunjite sunt prezentate strile pe care le poate avea obiectul Permis (invalid, activ, inactiv), iar n dreptunghiurile eliptice activitile pe care le poate executa obiectul aflndu-se n aceast stare.

Figura 12 - Diagrama de Stare/Activitate Permisn continuare se va caracteriza subsistemul Monitoring sistem de calcul. Diagramele care urmeaz (secven/colaborare) vor prezenta relaiile ntre actorii i obiectele din subsistem.

Figura 13 - Diagrama de colaborare Creare Utilizator

Not: Managerul utilizatorilor reprezint o utilitar a sistemului de operare de tip Server (sau program propriu).n diagrama dat se reprezint etapele de creare a unui utilizator. Astfel n aceast diagrama se urmrete etapele de prelucrare a informaiei ncepnd de la cererea de date prin introducerea a numelui i parolei noului utilizator, se verific dac exist un astfel de utilizator, dac s-a gsit dreptul de acces se elibereaz mai repede, dar dac nu procedura de creare a noului utilizator dureaz ceva mai mult timp.

Figura 14 - Diagrama de colaborare Logare sistemn cazul diagramei 14 fereastra de dialog reprezint o utilitar modificat a sistemului de operare care de obicei permite intrarea in sistem. Ca urmare a autentificrii cu succes are loc pornirea unei sesiuni de lucru (n mod abstract notat ca obiect).

Figura 15 - Diagrama de colaborare Transmite date VPNn diagrama 15 ca obiecte care interacioneaz sunt Aplicaiile A i B, respectiv funcionarii corespunztori care fac transfer de date utiliznd serverul utiliznd VPN(Virtual Private Network - Reea Privat Virtual)

Figura 16 - Diagrama de colaborare Transmite fiiern cazul ultimei diagrame, are loc transmiterea unor fiiere care au fost n prealabil criptate utiliznd algoritmi de criptare (n faza codificrii sistemului se va utiliza algoritmul simetric AES (Standard Avansat de Criptare)[4] care este destul de flexibil comparativ cu alii datorat lungimii variate a blocurilor de criptare, n combinaie cu un alt algoritm simetric SHA(Algoritm rezumat) [5] care corespunde standardului de securitate SHS, ales pentru stabilitatea i greutatea spargerii).Diagrama de Stare/Activitate corespunztoare acestui pachet (figura 17) prezint aciunile pe care le execut n paralel cele 2 aplicaii.

Figura 17 Diagrama Stare/Activitate Transfer3.1.3. Diagrame de claseUrmtorul pas n proiectare reprezint determinarea claselor de obiecte i a relaiilor ntre acestea: cea mai simpl metod ar fi analiza diagramei interaciunilor i depistarea acelor obiecte care fac parte din sistem. Pentru a evita erorile generate de necorespundere a referinelor (verificarea poate fi fcut prin raportarea necorespondenelor) e de dorit n timpul stabilirii mesajelor n diagramele de interaciune ca obiectele respective s fie instane a claselor din diagramele claselor corespunztoare. Pentru reducerea complexitii modelrii ntregului sistem, se va concentra doar la o serie de obiecte cu determinarea claselor respective, continund cu dezvoltarea n cod surs doar a unei diagrame (pentru comoditatea de elaborare la faza iniial).Pentru subsistemul Monitorizeaz persoane se realizeaz o clas aplicaie, cu alte obiecte componente instane ale altor clase. Respectiva aplicaie va realiza introducerea unei noi persoane n baza de date cu ulterioara perfectare a permisului de acces:

Figura 18 Diagrama claselor pentru AplicaieRespectiva aplicaie va avea 5 csue de introducere a datelor, 6 butoane realizarea operaiilor necesare, i un CheckBox n cazul n care persoana este un funcionar (permisul va putea fi folosit pentru logarea la calculator) toate instane a claselor corespunztoare. n cazul testrii corespunderii referinelor ctre aplicaie nu va fi raportat vreo eroare.Pentru subsistemul Monitoring sistem de calcul s-a realizat 2 aplicaii server i client destinate transferului securizat de date (n cazul nostru fiiere). Diagramele respective sunt:

Figura 19 - Diagrama claselor pentru Aplicatie Client

Figura 20 - Diagrama claselor pentru Aplicatie ServerPentru ambele diagrame am determinat cte un obiect de tip socket care sunt derivate de la acesta (Client_Socket i Server_Socket). Funciile membre ale acestor 2 clase Aplicaie corespund procedurilor care trebuie efectuate la recepionarea mesajelor de la cei 2 actori (figura 16). n cazul testrii referinelor nu se va raporta nici o eroare datorit faptului c toate obiectele ce aparin sistemului au fost reprezentate ca instane a claselor din diagramele claselor figura 20,21

Figura 21 Diagrama claselor SocketDup cum se vede cele 2 clase derivate motenesc toate proprietile i metodele clasei de baz. 3.1.4. Diagramele de componente

ntruct diagrama claselor reprezint o reprezentare logic a elementelor sistemului, reprezentarea fizic a acestora se realizeaz prin diagramele componentelor corespunztoare:

Figura 22 Diagrama componentelor pentru Socket Aici n cazul modificrii specificaiei pachetului Socket, se vor modifica respectiv i corpul pachetului Socket, precum i specificaiile pachetelor derivate, i deci n lan corpurile corespunztoare lor. n continuare vor fi prezentate diagramele de componente pentru fiecare din cele 3 aplicaii.

Figura 23 Diagrama componentelor Aplicaie Registraturn cazul acestei diagrame este inclus o baz de date de care depinde ntr-o oarecare msur aplicaia sub form de fiier executabil.

Figura 24 Diagrama componentelor Aplicaie Client

Figura 25 Diagrama componentelor Aplicaie Servern cazul figurii 24 i 25 fiierele executabile sunt AplicaieClient i AplicaieServer3.1.5. Diagrama de amplasare

A doua form de reprezentarea fizic a sistemului este diagrama de amplasare. Ea este utilizat pentru reprezentarea general a configurrii i topologiei sistemului de securitate distribuite i conine repartizarea componentelor dup nodurile sistemului, indicnd legturile fizice rutele de transfer a informaiei ntre echipamente.Ca ncheiere a modelrii este diagrama amplasamentelor care prezint componentele sistemului de securitate.

Figura 26 Diagrama amplasrii componentelor sistemului

CONCLUZIE

Realizarea acestei lucrri i-a pus drept obiectiv studierea modalitii de realizare a unui sistem complex, lund n consideraie paradigma Obiect Orientat, precum i specificul sistemului n cauz. Pentru realizarea acestei lucrri a fost nevoie de implementat metodologia Obiect Orientat, cu etapele de analiz i proiectare, realizate prin diferite modele ale sistemului. Utilizarea limbajului UML a uurat nelegerea cerinelor, precum i realizarea acestora sub form de componente cu legturile ntre acestea. La elaborarea modelului m-am bazat pe principiile limbajului UML, folosind ca instrument de lucru mediul Enterprise Architect. Limbajul UML uureaz elaborarea, vizualizarea i documentarea modelelor, ceea ce permite o proiectare rapid a sistemelor, prin accentuarea ateniei asupra aspectelor necesare proiectrii. Analiznd sistemul dat n baza metodologiei Obiect Orientat i trecnd prin etapele planificrii, sincronizrii i analizei am dezvoltat modelul dat n diagramele de interaciune i diagramele claselor n care am descris fiecare caz de utilizare prin interaciunea dintre obiecte.O dat cu acumularea cunotinelor n domeniul transferului de informaie n reele va fi posibil dezvoltarea de mai departe a sistemului dat de securitate.

BIBLIOGRAFIE

1. http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf (Joan Daemen, Vincent Rijmen The Rijndael block cipher)2. http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf (Federal Information Processing Standards Publication 180-2 Secure Hash Standard)3. Description of SHA 256, SHA 384, SHA 512 (fiier pdf, englez)4. Criptografia (fiier pdf, romn)5. http://en.wikipedia.org/wiki/Unified_Modeling_Language

26