R O M N I A MINISTERUL APRRII ACADEMIA TEHNIC MILITAR ing. VDUVA CLIN MARIN REZUMAT TEZ DE DOCTORAT TEM:SECURITATEA APLICAIILOR WWW N COMERUL ELECTRONIC Conductor de doctorat: Prof. univ. dr. ing. VICTOR-VALERIU PATRICIU BUCURETI 2007 Ctre, Vaducemlacunotincnziuade23.02.2007,ncepndcuora13.00,n Aula Magna a Academiei Tehnice Militare, va avea loc susinerea public a tezei de doctorat intitulat Securitatea aplicaiilor WWW n comerul electronic elaborat deinginerVduvaClinMarinnvedereaobineriititluluitiinificde "DOCTOR"ndomeniul"TIINACALCULATOARELOR,cuurmtoarea comisie: PREEDINTE:Lt.col. Prof. univ. dr. ing. Ioan NICOLAESCU CONDUCTOR DE DOCTORAT: Prof. univ. dr. ing. Victor-Valeriu PATRICIU REFERENI:1. Prof. univ. dr. ing.Valentin CRISTEA Universitatea Politehnic Bucureti 2. Prof. univ. dr.Ion IVAN Academia de Studii Economice Bucureti 3. Prof. univ. dr. ing.Adrian ATANASIU Universitatea Bucureti n acest scop, v trimitem alturat rezumatul tezei de doctorat i v invitm s participai la susinerea public aacesteia. ncazulncarebinevoiisfaceieventualeaprecierisauobservaiiasupra coninutului lucrrii, v rugm s le trimitei n scris, pe adresa: Academia Tehnic Militar,Bucureti,bulevardulGeorgeCobucnr.81-83,sectorul5, cod 050141; Fax 40 21 - 335 57 63; E-mail:rgr|gore_rla.ro RECTORUL ACADEMIEI TEHNICE MILITARE Colonel prof. univ. dr. ing. Doru-Gheorghe SAFTA SECRETAR EF Colonel conf. univ. dr. ing. Marian BUNEA Securitatea aplicaiilor WWW n comerul electronic Pagina 1 / 55 Cuprins Introducere ............................................................................................................................... 4 Capitolul. 1Comerul electronic ............................................................................................... 8 1.1Cadrul general - cerine ................................................................................................... 8 1.2Instrumente de baz n comerul electronic .................................................................... 8 1.2.1Crile de credit .................................................................................................................... 9 1.2.2ATM-uri ............................................................................................................................... 9 1.3Scheme de plat n comerul electronic .......................................................................... 9 1.3.1Cecuri electronice ................................................................................................................. 9 1.3.2Sisteme de plat cu carduri ................................................................................................... 9 1.3.3Sisteme de plat bazate pe bani electronici ........................................................................ 10 1.4Standarde n domeniu ................................................................................................... 10 1.4.1CEPS - Common Electronic Pursue Specifications ........................................................... 11 1.4.2Alte standarde..................................................................................................................... 11 Capitolul. 2Prezentare arhitecturi software distribuite ........................................................... 12 2.1Arhitecturi 2-tier ............................................................................................................. 12 2.2Arhitecturi software 3-tier .............................................................................................. 12 2.3Arhitecturi distribuite web .............................................................................................. 12 2.4Poziionarea reelei n arhitecturile distribuite ............................................................... 12 2.5Securitatea n arhitecturi distribuite ............................................................................... 13 2.6Prezentare tehnologie Java ........................................................................................... 13 2.6.1Dezvoltarea i execuia unei aplicaii Java. ........................................................................ 13 2.6.2Dezvoltarea i execuia unui applet Java. ........................................................................... 13 2.6.3Arhitectura sistemului Java ................................................................................................ 13 Capitolul. 3Autentificarea n sisteme software ...................................................................... 14 3.1Clasificare autentificare ................................................................................................. 14 3.2Delegarea ...................................................................................................................... 15 3.3Metode avansate de autentificare ................................................................................. 15 Capitolul. 4Autorizarea n sisteme software .......................................................................... 16 4.1Definire .......................................................................................................................... 16 4.2Modele-politici de control acces .................................................................................... 16 4.3RBAC ............................................................................................................................. 16 4.4Modelul de baz RBAC. ................................................................................................ 17 4.4.1Definiiile matematice ale modeluluiRBAC de baz ....................................................... 17 4.5Modelul ierarhic RBAC. ................................................................................................. 18 4.5.1Definiiile matematice ale modeluluiRBAC ierarhic ....................................................... 18 4.6Modelul SSD RBAC....................................................................................................... 19 4.6.1Definiiile matematice ale modeluluiRBAC - SSD .......................................................... 19 Securitatea aplicaiilor WWW n comerul electronic Pagina 2 / 55 4.7Modelul DSD RBAC. ..................................................................................................... 20 4.8Model de Autorizare n aplicaii distribuite Java modelul EJB .................................... 20 Capitolul. 5Comunicarea securizat n sisteme software distribuite ..................................... 21 5.1SSL Secure Socket Layer .......................................................................................... 21 5.1.1Protocolul SSL ................................................................................................................... 21 5.1.2Algoritmi de criptare utilizai de SSL ................................................................................ 21 5.1.3Protocolul Handshake SSL ................................................................................................. 22 5.2Sercuritatea n comunicarea cu serverele web ............................................................. 22 5.2.1Comunicarea ...................................................................................................................... 22 5.2.2Autentificarea serverelor WWW ........................................................................................ 22 5.3Asigurarea unei comunicri securizate client server ................................................... 23 5.3.1Comunicare securizat prin socket Java .......................................................................... 23 5.3.2Comunicare securizat prin RMI ....................................................................................... 23 Capitolul. 6Reguli de scriere cod securizat ........................................................................... 24 6.1Principii de asigurare a securitii .................................................................................. 24 6.2Etapele de dezvoltare al unui soft securizat .................................................................. 24 6.3Probleme de codare Javaprin prisma securitii ......................................................... 24 6.4Stocarea sigura datelor ............................................................................................. 24 6.4.1Protejarea datelor secrete ................................................................................................... 24 6.4.2Accesarea i stocarea sigur a datelor ................................................................................ 24 Capitolul. 7Framework de securitate pentru sisteme distribuite ........................................... 25 7.1Cerinele propuse .......................................................................................................... 25 7.2Concepte utilizate .......................................................................................................... 27 7.3Modelul de securitate propus ........................................................................................ 28 7.4Arhitectura sistemului de securitate .............................................................................. 30 Capitolul. 8Modulul de autentificare ...................................................................................... 32 8.1Diagrame de lucru ......................................................................................................... 32 8.1.1Procesul de autentificare .................................................................................................... 32 8.1.2Procese de lucru cu tichetul de autentificare ...................................................................... 32 8.2Arhitectura modulului de autentificare ........................................................................... 34 8.3Interfaa cu modulul de autentificare ............................................................................. 35 Capitolul. 9Modulul de autorizare .......................................................................................... 36 9.1Ce trebuie protejat ......................................................................................................... 36 9.2Unde se face autorizarea .............................................................................................. 37 9.3Procesul de autorizare .................................................................................................. 38 9.4Arhitectura modulului de autorizare............................................................................... 39 9.5Interfaa cu modulul de autorizare ................................................................................. 40 Capitolul. 10Modulul de audit .................................................................................................. 41 10.1Concepte ....................................................................................................................... 41 Securitatea aplicaiilor WWW n comerul electronic Pagina 3 / 55 10.2Arhitectura ..................................................................................................................... 41 10.3Diagrame de lucru ......................................................................................................... 42 10.3.1Procesul de auditare ........................................................................................................... 42 10.4Interfeele modulului de audit ........................................................................................ 43 Capitolul. 11Modulul de Framework Manager ........................................................................ 44 11.1Concepte ....................................................................................................................... 44 11.2Arhitectura ..................................................................................................................... 45 11.2.1Nivelul de interfaare .......................................................................................................... 45 11.2.2Nivelul de sesiune .............................................................................................................. 45 11.2.3Nivelul de autorizare .......................................................................................................... 46 11.2.4Nivelul de logic ................................................................................................................ 46 Capitolul. 12Framework de configurare pentru sisteme distribuite ......................................... 47 12.1Cerinele propuse .......................................................................................................... 47 12.2Concepte utilizate .......................................................................................................... 47 12.3Modelul propus .............................................................................................................. 48 12.4Arhitectura sistemului .................................................................................................... 49 12.5Structuri de date ............................................................................................................ 49 12.6Structura Interfa de acces .......................................................................................... 49 Capitolul. 13Aspecte legate de proiectarea modulelor............................................................ 51 13.1Modelul dinamic de date ............................................................................................... 51 13.2Modulul de autentificare ................................................................................................ 51 13.3Modulul de autorizare .................................................................................................... 51 13.4Modulul de audit ............................................................................................................ 51 Capitolul. 14Sinteza contribuiilor tezei ................................................................................... 52 Capitolul. 15Bibliografie selectiv ............................................................................................ 54 Securitatea aplicaiilor WWW n comerul electronic Pagina 4 / 55 I In nt tr ro od du uc ce er re e SecuritateaaplicaiilorWWWncomerulelectronicesteunaspectdeosebitdecomplexcare implicocategorielargdesubiecteiprobleme.Dintreacestesubiecteputemsamintim urmtoarele:protocoaleledeplatelectronic,securitateacomunicriinaplicaiileweb, dezvoltareasite-urilordevnzareon-line,aspecteledearhitectursoftwarecaresacopere cerinele de securitate,etc. n ceea ce privete comerul electronic exist n momentul de fa un set bine stabilit de scheme pentru partea de pli electronice. De asemenea n ceea ce privete comunicareasecurizatexistunsetdeprotocoalelargrspnditepepia.nacestcontext subiectulncareamconsideratcsepoateaduceunaportmaiimportantestelegatde dezvoltarea unor arhitecturi software care s acopere cerinele cele mai complexe desecuritate aleuneiaplicaiidecomerelectronic.Desigursubiectultratatacopernunumaiaplicaiilede comerelectronic,ciocategoriemailargdeaplicaiisoftwaredistribuitencareaspectelede securitatesuntimportante.Tezai-apropustratareaunuisubiectdemarecomplexitaten domeniuldezvoltriiaplicaiilorsoftwaredistribuite,maiexact,aspectulsecuritiiacestor aplicaii.Securitateandezvoltareaaplicaiilorsoftwaredistribuiteesteunsubiectcomplexcare implic un set variat de probleme precum i o varietate mare de soluii la aceste probleme. Teza i-a propus s treac ntr-o prim faz n revistaceste probleme precum i soluiile existente n momentul de fa pe pia. Odat ce s-a fcut o analiz aproblemelor-soluiilor din domeniu o partedeosebitdeimportantatezeiesteaportulautoruluilasoluiiledesecuritateactuale precum i integrarea soluiilor ntr-un cadru de dezvoltare unitar.Teza a avut ca i obiectiv major modelarea unor soluii de securitate care s acopere n ct mai mare parte cerinele unui sistem software distribuit, n special cerinele de securitate ale unei aplicaii WWW de comer electronic.naceastidees-auacoperitmaimulteaspectedesecuritatealeunuisistemsoftware: autentificarea,autorizarea,auditul,comunicarea,etc.Pentrufiecareaspectaufoststudiate diferite modele existente i s-au propus noi modelei mbuntiri la aceste modele. Un aspect important care este urmrit de tez este cel de integrare a acestor modele ntr-un mod unitar. Capitolul 1 face o sinteza mai multor aspecte legate de comerul electronic oferind o viziune de ansambluasupradomeniuluiiasupracomplexitiiproblemelor.ntr-oprimpartesunt prezentate cerinele unui sistem de comer electronic subliniind n special cerinele de securitate: identificarea,autentificarea,autorizarea,confidenialitatea,integritateadatelor,non-repudierea. Acestecerinesuntcerinelefundamentalecarestaulabazaframework-uluipropus.Unalt aspect tratat n acest capitol se refer la setul de instrumente de baz pentru comer electronic, cumarficriledecredit.Aufostprezentatediferiteschemedeplatncomerulelectronic: cecuri electronice, sisteme bazate pe carduri, bani electronici.n contextul sistemelor bazate pe cardurisuntconsideratedouprotocoaleimportantepentrucomerulelectronicpeweb:pli peste SSL i protocolul SET. Un alt aspect prezentat se refer la banii electronici i modalitatea caacetiasfieutilizaintranzaciilecomerciale.nfinalulcapitoluluisefaceoprezentarea unor standarde din domeniu, o importan mai mare acordndu-se standardului CEP. Capitolul2trecenrevistcelemaicunoscutemodeledearhitecturidistribuite.Astfels-au prezentat modelele de arhitecturi distribuite de tip 2-tier, 3-tier i arhitecturi distribuite pentru web. Scopulacesteitrecerinrevistesteprezentareamodulelor/nivelelorexistentenarhitecturile distribuite, identificnd astfel punctele ce au impact asupra securitii. De fapt capitolul 2 acoper ntrebareaCetrebuieprotejat?.Totncapitolul2seprezintaspecteledesecuritatecare trebuieluate nconsiderare ntr-unsistemdistribuit.Maiexactsediscutpescurt aspectelede autentificare,autorizare,comunicaresecurizat,auditareoperaii,aspectecaretrebuieluaten calcul atunci cnd discutm desprece trebuie protejat. inndcont c nvederea implementrii cadrului de securitate am luat ca i referin de implementare tehnologia Java, o tehnologie care sepreteazladezvoltareadeaplicaiidistribuitecomplexe,amconsideratnecesarotrecere scurt n revist a bazelor acestei tehnologii i a unor aspecte eseniale de lucru cu Java.Securitatea aplicaiilor WWW n comerul electronic Pagina 5 / 55 Capitolul2defaptfaceointroducerescurtndomeniularhitecturilordistribuiteindomeniul tehnologiei Java, domenii n care se face util cadrul de securitate ce face subiectul acestei teze. nurmtoareaparteatezeiamtrecutnrevistoseriedeaspecteimportantedesecuritate. Astfelfiecare aspect desecuritatea fostanalizatndetaliuis-a ncercat o trecere n revista domeniului precum a soluiilor actuale.Capitolul3 estededicatsubiectuluide autentificarea utilizatorilor n sistemesoftware. nacest capitolse prezintproblema autentificrii ice reprezintautentificarea ntr-unsistemsoftware. Diferite aspecte conexe autentificrii au fost prezentate n acest capitol. Un astfel de aspect este aspectuldelegrii.Capitolul3faceoclasificareadiferitelortipurigenericedeautentificare: unilateral,mutual,mediatiprezintoseriedemecanismeutilizatenpractic.Cai contribuiepersonal,naceastpartes-afcutoanalizaavantajelor-dezavantajeloracestor mecanisme,is-aupropusdiferitevariantedembuntirealeacestormecanisme.Totn capitolul3s-afcutotrecerenrevistamodalitilordeautentificareavansate,bazatepe diferite tehnologii biometrice sau pe alte dispozitive hardware de autentificare. Capitolul4vizeazunaltaspectimportantnsecuritateasistemelorsoftwareicarepoatefi considerat poate aspectul cel mai critic i mai dificil de gestionat ntr-un sistem software complex. Mai exact acest capitol este dedicat autorizrii n sisteme software. Odat definitce nseamn autorizareansistemesoftwares-auprezentatdiferiteabordriexistentepepialegatede autorizare.Diferitemodeleaufosttrecutenrevist.Astfels-audiscutatconcepteledeACL, modeleleMACiDAC.Acesteaaufostprezentatepescurtnideeacpotficonsiderate abordrimaivechindomeniu.Capitolul4s-aopritnspecialasupramodeluluiRBACRole BaseAccessControlaacumesteprezentatdegrupulFerraiolo,KuhniChandramouli. ModelulRBACafostanalizatndetaliudiscutndtoatecele4componentealeacestuimodel: modelul de baz RBAC, modelul ierarhic RBAC, modelul SSD i modelul DSD. Avnd n vedere importanaacestuimodelnsecuritateaunuisistemsoftware,s-auprezentatndetaliu componentele prezente n aceste modele, relaiile ntre ele precum i reprezentrile matematice aleacestora.Totnacestcapitolsediscutmoduldeimplementarealautorizriincadrul arhitecturiiEnterpriseJavaBeans,subliniindcomplexitateaabordriiprecumiamodalitii destuldecomplicateprincareprogramatorulimplementeazautorizarealaniveldesistem software. Capitolul5dintezseadreseazunuialtsubiectimportantlegatdesecuritateimaiexact comunicrii securizate n sisteme distribuite. n acest capitol s-au prezentat modalitile cele mai potrivitepentruaasiguraocomunicaresecurizatntrediferitemodulealeuneiaplicaii.n aceastideeomareatenieafostacordatprotocoluluiSecureSocketLayer,fiindunprotocol standarddecomunicaresecurizat.Deasemeneaaufostdiscutatesoluiilestandardde comunicare securizat n cazul lucrului cu aplicaii web.Avnd n vedere c tehnologia Java st labazaframework-uluipropusnacestcapitols-auprezentatsoluiileJavadecomunicare securizatclient-server.Aicis-aluatndiscuieimplementareaSSLnJavaprecumi comunicarea securizat la nivel RMI. Capitolul 6 din tez afost dedicat unuialtaspect important al securitii unuisistem software i maiexactregulilorcaretrebuiesleurmezedezvoltatoriipentruascrieuncodsecure.n aceast idee s-apornit de laprincipiiledebaz pentru asigurarea securitii, urmrind etapele dedezvoltarealeunuisoftsecurizatajungndlaadiscutadetaliidecodareJavalegatede securitate precum i modul de lucru cu bazele de date pentru a asigura securitatea. Acest capitol a ncercat s adune un set de reguli i de principii care trebuie urmate de dezvoltatori n scrierea unui cod ct mai securizat. Cucapitolul6altezeiseterminparteadeanalizisintezasubiectelordesecuritate,a diverselorproblemeiasoluiilorexistente.Parteaceurmeazdupacestcapitolprezint abordrioriginaleimbuntirialesoluiilorprezentateanterioravndcaobiectivfinal conceptualizareairealizareaunuicadrudesecuritatecaresoferesoluiilacelemaimulte probleme de securitate existente n dezvoltarea unui sistem distribuit.Capitolul 7 al tezei ofer o abordare original pentru implementarea unui framework de securitate pentru sisteme distribuite. Astfel ntr-o prim faz se definesc cerinele care ni le propunem de la unastfeldeframeworkviznddiferiteaspectelegatedesecuritate.Totnacestcapitolse prezintconcepteleutilizateientitilecaresuntimplicatenmodelareasoluiei.Opartedin acesteconceptesaumaiexactmodulncareconceptelesuntintegrateprezintoviziune Securitatea aplicaiilor WWW n comerul electronic Pagina 6 / 55 original a modului de abordare a securitii unui sistem distribuit. Modelul de securitate propus n acest capitol reprezint o propunere mbuntit a modelelor existente in literatur integrnd modelul RBACstandard cu alte concepte, precumi cu alteentitiexterne sistemului.Modelul propusaduceovariantoriginaldeintegrarentr-unsistemrealdistribuit.Modelulvinecu elementenoiattdinpunctdevederealautentificrii,ctialautorizriinsistemedistribuite.Un element important n acest model este integrarea cu diferii conectori externi vzui ca surseaunorinformaiidesecuritate.Totncapitolul7sedescriearhitecturasistemuluipropus precumimodalitateadeintegrareaacestuiantr-unsistemsoftwaredistribuit.Arhitectura descriemodulncarecomponenteleprincipaledesecuritate,SecurityFrameworkManager, ModululdeAutentificare,ModululdeAutorizare,ModululdeAuditsuntintegratensistem precum i ofer o prezentare scurt a rolului fiecrui modul n ansamblul propus. Capitolul8altezeioferoperspectivmaidetaliatasupraModuluideAutentificare.ntr-o primparteacapitoluluisedescriucerinelevizatedeacestmodulprecumimodalitateaprin care acest moduli propune s realizeze autentificarea utilizatorilor. Original n aceast parte estemodalitateancaremodululdeautentificareconecteazdiferitesursedeautentificare externeprecumialteaspecteintegratenarhitecturaacestuimodul.Dintreacesteaspectese cuvine s menionm: integrarea unui suport de tichet de autentificare, blocul de detecie intrui, mapareapebazdereguli.Fiecaresub-modulestedescrisndetaliudelimitnd responsabilitilefiecruisub-modulnparteadeautentificare.Totncapitolul8sedescrien detaliu interfaa de comunicare a modulului de autentificare cu celelalte module. Aceast interfa estedeosebitdeimportant,reprezentndcontractuldintremodululdeautentificareirestul sistemului software. Capitolul 9 al tezeiprezint n detaliu Modulul de Autorizare.ntr-o prim parte a capitolului se faceostructurare-clasificareamoduluincareresurselesoftwareartrebuianalizaten contextul autorizrii.Aceast clasificarei dorete s clarifice ce poate fi/ar trebuiprotejat ntr-un sistem software. Tot n acest capitol se clarific unde se poate face autorizarea ntr-un sistem softwaredistribuit.Defaptproblemaautorizriipoateatingediferiteniveledinarhitectura software. O alt parte a capitolului 9 prezint modul de realizare al autorizrii discutndetapele implicate n acest proces la diferite nivele. Ca i n cadrul modulului de autentificare i modulul de autorizare este descompus n sub-module evideniind responsabilitatea fiecruia dintre aceste sub-moduleprecumicuminteracioneazfiecarecurestulansamblului.Interfeelede comunicaredintremodululdeautorizareirestulsistemuluisuntdeosebitdeimportanten clarificarea responsabilitilor acestui bloc.Capitolul10estededicatmodululuideaudit.Unsistemdesecuritatebinestructurattrebuies coninobligatoriuopartedeauditare.Estefoarteimportantcatoateaciunileutilizatorilors poat fi urmrite pentru a nelege eventualele modificri de stare a unui sistem software precum i momentul cnd au aprut ele. n acest context s-a propus o soluie originalpentru a structura informaiacaresevaaudita,permindastfeloauditarecorespunztoareaaciunilor utilizatorilor.Soluiapropusacoperecerinelecelormaicomplexerapoartecaresedorescs fiegeneratedinaudit.Oaltparteacapitoluluiprezintmodulncaredecurgeprocesulde auditareicareesteflow-uldelucru.Caincazulcelorlaltemodule,nacestcapitols-au prezentatsub-moduleleimplicatenauditidentificndresponsabilitilefiecruisub-modul. Interfeele de comunicare dintre modulul de audit i restul sistemului este un alt aspect important tratat n acest capitol.n capitolul 11teza se concentreaz asupra modulului de SFM (Security Framework Manager = FrameworkManager).Acestmodulreprezintliantulcelorlaltemodulediscutatepnacumi oferperspectivadeinterconectareaaltormoduledebusinessnsistem.Capitolulprezint arhitectura,maiexactdiferitenivelurideresponsabilitatealeacestuimodul.Suntdiscutate anumiteaspecteavansatedeconectareamodulelordebusinessprecumiaspectelegatede moduldeasigurareaunuitimpderspunsbun,auneitoleranebunelacderidesistem-module precum i modul de a asigura o comunicare securizat.Capitolul12estededicatmoduluideconfigurarealunuiastfeldesistem.inndcontde complexitateasistemuluidiscutat,precumidediverselescenariipecareleputemavean practic,moduldeconfigurareesteunmodulimportantnacestcontext.naceastidees-au propusoseriedesoluiieficientedestructurareainformaieideconfigurare.Acestcapitol prezint structura unui modul de configurare precum i interfeele sale de acces. Securitatea aplicaiilor WWW n comerul electronic Pagina 7 / 55 Capitolul 13 prezint aspecte legate de design-ul detaliat al celor mai importante pri din sistem i al unor elemente informatice cheie. n aceast parte s-au prezentat elemente de detaliu legate de proiectarea i implementarea sistemului, elemente care ns sunt eseniale pentru nelegerea unoraspecteimportantealeframework-ului.Acesteelementeprezintideioriginaleiconfer valoare framewok-ului prin prisma flexibilitii i scalabilitii sistemului. Capitolul14,Sintezacontribuiilortezeifaceotrecerenrevistaelementelorcucaracterde noutate i originalitate a tezei. n final vreau s mulumesc pe aceast cale conductorului de doctorat,domnului Prof. Dr. Ing. Victor-Valeriu Patriciu pentru sprijinul acordat n elaborarea tezei i pentru sfaturile i ndrumrile dintoataceastperioad.Cusiguransprijinulsuafostunulhotrtorpentrufinalizarea tezeiipentrufructificareanformaactualarezultatelorobinutenultimiianincariera academic i de dezvoltator software.DeasemeneavreausmulumesccolegiloriprofesorilordelaUniversitateaTehnicCluj-Napocapentrusfaturileiopiniileloripentrutotsuportulacordatpedireciaacademic.n special mulumesc doamnei Prof. Dr. Ing.Monica Borda pentru direciile i ndrumarea oferit la nceputulcariereimeleacademiceprecumidomnuluiProf.Dr.Ing.AurelVlaicupentru ndrumrileisugestiileoferite.naceeaiideevreausadresezmulumirilemeleclduroase colegilordincolectivulfirmeiFortechpentrusprijinulacordatnconcretizareapractica rezultatelor i conceptelor propuse n aceast tez.Mulumescmembrilorcomisiilordeexameneireferateprevzutenplanulindividualde pregtirepentruexigenasirecomandrilelor,careauavutconduslaunstudiuaprofundati vast n domeniul securitii sistemelor web. nspecial,inunultimulrndvreausmulumescfamilieimele,soieimeleicopiilormei pentrunelegereaacordatntoataceastperioadipentrutotsprijinulmoral,careafost hotrtor n unele momente.Securitatea aplicaiilor WWW n comerul electronic Pagina 8 / 55 C Ca ap pi it to ol lu ul l. . 1 1C Co om me er r] ]u ul l e el le ec ct tr ro on ni ic c 1 1. .1 1C Ca ad dr ru ul l g ge en ne er ra al l - - c ce er ri in n] ]e e Comerul electronic implic pe lng chestiunile de natur tehnic, un larg set de alte domenii pe care va trebui s le analizm. n continuare n acest capitolne vom concentra asupra sistemelor deplatncontextulcomeruluielectronic.Chestiunilelegatedeacestsubiectpotfigrupaten opt categorii mari: bani electronici (e-money) produse pe baz de acces (enhanced access products) soluii de micropli (micropayment) infrastructuri de sisteme de plat regularizarea i inovarea(regulation and innovation) standardizarea i interoperabilitatea protecia consumatorului caracterul anonim, privati sigur integrarea plailor n tranzacii on-line Pentruaasigurasuccesulunuisistemdeplatelectronicpepiaestenevoiecaacestas asigureunsetdecerineprincipalecaresuntlegatedenevoileclieniloriavnztorilor.Din punct de vedere al securitii se pot identifica 6 nivele de securitate: Identificarea(Identification)implicprezentareatuturorprilorimplicatepentrua cunoate cine i ia angajamentul i cine profit de anumite drepturi.Astfel cumprtorul esteobligatsplteasc(existrisculdeanuplti)ivnztorulesteobligats furnizeze produsele comandate (exist riscul dea nu furniza produsul). Autentificare(Authentication)esteprocesulprincareseverificcambelepri contractante sunt ceea ce pretind afi. Autorizarea(Authorization)procesulprincareseacorddreptuldeaexecutao operaie. Confidenialitatea (Confidence) este important s se garanteze c nici o informaie nu se va face cunoscut unei a treia pri. Sistemul trebuie proiectat astfel nct nici o parte s nu aib acces la date de care nu are nevoie pentru a efectua serviciul.Ca exemplu, ntranzaciacucardurideplat,bancanutrebuiescunoascprodusulsauserviciul care se pltete iar vnztorul nu trebuie s aib acces la numrul de card. Integritatea datelor (Integrity of data) ambele pri trebuie s fie asigurate c n timpul procesului de transmisie, datele nu au fost schimbate i au fost furnizate ca un ntreg. Ne-repudierea(Non-repudiation)sistemeledeplattrebuiesinterzicclientului posibilitatea de a nega faptul c el a fcut plata. Scalabilitate sistemele de plat trebuie s ia n considerare schimbrile de dimensiune aleactivitii.Sistemeledeplatnutrebuiesfieblocatedacsecretenumrulde clieni sau valoarea tranzaciilor.n caz contrar,clienii vor percepesistemul ca ne-fiind de ncredere i se vor opri s fac tranzacii.

1 1. .2 2I In ns st tr ru um me en nt te e d de e b ba az z n n c co om me er r] ]u ul l e el le ec ct tr ro on ni ic c n acest capitol s-au discutat aspecte legate de principalele instrumente de la care s-a dezvoltat comerulelectronic(criledecredit,ATM-uri)trecndnrevistmodalitilencareacestea lucreaz i interacioneaz precum i principiile de baz care stau la funcionarealor. Securitatea aplicaiilor WWW n comerul electronic Pagina 9 / 55 1.2.1Cr]ile de credit O carte de credit (creditcard) esteocarteldeplastic, deobiceidedimensiuni8.5 cm/5.5cm, careconineinformaiideidentificarecumarfisemnturasaupoza,icare,autorizeaz persoanarespectivsplteasccumprturisauserviciincontulsu,plipentrucareva decontaperiodic.InformaiiledepecardsuntcititedeAutomatedTellerMachinesATM,de cititoarele de la magazine, de bnci sau de computere de pe Internet. Fiecare card are pe spate o band magnetic care are 3 piste (track). Aceast band conine o serie de informaii care sunt cititedecititoareleATM-uluisaudectrecititoruldelamagazin.Informaiastocatpecele3 piste este definit de standardulISO/IEC 7811. n mod obinuit doar pistele 1 i 2 sunt utilizate de cartea decredit. Pista 3 este de tipscriere/citire (includeuncodPIN criptat,un cod de ar, unitatea de bani i suma autorizat) dar utilizarea ei nu este standardizat ntre bnci. 1.2.2ATM-uri UnATMesteunterminaldedatecarearedoudispozitivedeintrareipatrudispozitivede ieire.Ca i orice alt terminal de date, ATM-ul este conectat i comunic cu un procesor gazd. UnprocesorhostesteopoartprincarediferitereeleATMpotfiaccesatedeproprietarul cardului. n momentul n care un posesor de card dorete s fac o tranzacie ATM, el furnizeaz toateinformaiilenecesareprinintermediulcarduluiiatastaturii.ATM-ultrimiteaceste informaii la procesorul gazd care ruteaz cererea de tranzacie la banca sau la instituia care a eliberatcardul.Dacs-aceruteliberareadenumerar,procesorulhostcomandtransferul (electronicfundstransfer) din contulclientului ncontulprocesorului gazd. Odatces-a fcut transferul ctre contul procesorului gazd, acesta trimite un cod de acceptare ctre ATM pentru a autorizadistribuiadenumerar.ApoiurmeazprocesuldeautomatedclearinghouseACH prin care se transfer fondul de pe carduri n contul vnztorului. 1 1. .3 3S Sc ch he em me e d de e p pl la at t n n c co om me er r] ]u ul l e el le ec ct tr ro on ni ic c nacestcapitols-autrecutnrevistdiferitesistemedeplatelectronicprezentndmoduln care acestea lucreaz precum i diferite probleme n utilizarea lor. n general exist trei sisteme de platelectronic: cecuri electronice, sistemede plat bazate pediferite protocoalei carduri de plat, bani electronici 1.3.1Cecuri electronice Cecurile electronice reprezint un concept care leag ideea de cecuri tradiionale cu sistemele de plat electronic. Deoarece semntura electronic este posibil din punct de vedere tehnologic, i aceast procedur este legal n mai multe ri, nu exist nici o barier real care st n calea dezvoltrii acestui sistem. Singura problem, este legat de obiceiurile oamenilor care pot face dezvoltarea sistemului dificil. Un exemplu de sistem de cec electronic tratat n aceast seciune esteeCheck.Principiulgeneralestesimilarcucelalcecurilortradiionale:semnatarulcecului genereazuneCheck,utiliznddeexempluunsmartcard,apoilsemneaziltransfer electronic labeneficiar. Acesta din urm primete cecul, verific semntura,aprob eCheck-ul, scrieundepozitisemneazdepozitul.Bancabeneficiaruluiceculuiverificpltitoruli semnturancasatorului,crediteazcontulncasatoruluiitrimitececulpentrucliringipentru decontare.Bancapltitoruluiverificsemnturapltitoruluiidebiteazcontulpltitorului, semneazi depoziteazcecul n banc, dup careaplic metodeletradiionale decliring ntre bnci. 1.3.2Sisteme de plat cu carduri Sistemeledeplatprincardurielectroniceimplicutilizareacardurilorpentruplatnreele deschise. Cardurile folosite sunt cele care sunt utilizate pentru ATM-uri sau pentru plata direct la vnztorfolosindcititoareelectronicedecarduri.Sefolosescaceleaitipuridecarduri,dar informaiiletrimisepentruplatsuntlegatedenumruldeidentificarecard.Caurmare informaiilecaresetransmitnreeleledeschise(genInternet)trebuiesfiestrictprotejate.n timpultransmisieinumruluidecardprinreeledeschisecumarfiInternetul,potaprea urmtoareleprobleme:eavesdropping-posibilitateainterceptriinumruluidecard, Securitatea aplicaiilor WWW n comerul electronic Pagina 10 / 55 tamperinginterceptareadatelororiginaleimodificarealorfrcaemitoruls-idea seama,impersonatingposibilitateca,cunoscnddetaliileunuicard,opersoanspretind caarfialtcinevatransmindastfelordinedeplatpentrumagazinevirtuale.Pentruapreveni acestetipuridefraudeexistoseriedeprotocoalecares-auproiectaticaresedezvoltn continuare.Generalvorbindputemspunecexistdoutipurideprotocoalecareasigur protecia plilor n timpul transmisiei n reele deschise: protocoale de securitateacomunicaiei - stabilesc un sistem de reguli care guverneaz ntregul proces de comunicaie.Un exemplu de astfel de protocol este protocolul Secure Socket Layer SSL (prezentat ntr-un alt capitol).Printr-un astfel de protocol, numerele decardurisepottransferactrevnztor,protejatempotrivafurtuluiimodificrii informaiei n timpul transmisiei. Totui un astfel de protocol nu protejeaz mpotriva ne-repudieriisauutilizriifrauduloaseanumerelordecard,deoarecevnztoriistocheaz toate informaiile confideniale ale cardului clientului pe serverele lor. protocoale de securitateaplilor- aceste protocoale acoper toatecerinele deplat i suntspecialconceputepentruplileelectronice.nacestcontexts-aprezentati discutatnacestcapitolprotocolulSETprecumicomponentelecarestaulabaza acestui protocol: Portofel electronic,Point-of-Sale, Gateway ul pentru plat, Autoritatea de Certificare. De asemenea n acest capitol s-a fcut o comparaie ntre SET i plile prin SSL. 1.3.3Sisteme de plat bazate pe bani electronici Acestcapitolafostdedicatprezentriisistemelordeplatbazatepebanielectronici,a caracteristicilorlorprecumiaprincipiilordupcareacesteafuncioneaz.Baniielectronicinu suntunprodusdeaccescumarficecurile,transferurilebancare,carduriledeplat,etc.Ei constituie n acelai timp un instrument de plat i o valoare monetar, opernd astfel ca ibanii numerar.Exist dou mari categorii de bani electronici (e-money): Produse bazate pe software software based products (SBP) Produse bazate pe carduri card based products (CBP) O alt mprire se poate face dup criteriul de sistem deschis: sistemenchise-aanumitschemcubuclnchissausistemon-line.Sistemele nchisesuntbazatepeunintermediarputernic,careimpliccontactdirectnmomentul n care se cheltuiesc sau se primesc banii.sisteme deschise -aa numit schem cu bucl deschis sau sistem off-line. Sistemele deschise, permit utilizatorilor s efectueze tranzacii fr a implica vreun intermediar.O alt distincie se poate face dup caracterul anonim al banilor electronici: banielectroniciidentificai.Baniielectroniciidentificaiopereazsimilarcuprodusele bancaredeoareceidentitateautilizatoruluiicaleadeplatestecunoscutinstituiilor financiare i ca urmare se poate urmri uor circulaia banilor electronici n economie. bani electronici anonimi. Banii electronici anonimi nu pot fi urmrii, fapt ce creeaz un nounivelmonetar-cashimaterialcarecombinavantajeleidezavantajelebanilor numerar ia mediuluielectronic. Pentrua crea bani anonimi estenevoie de semntur oarb. Adevrata substituie a banilor numerar este asigurat cnd sistemul este n acelai timp anonim i off-line. 1 1. .4 4S St ta an nd da ar rd de e n n d do om me en ni iu u nacestcapitols-auprezentatpescurtdiferitestandardendomeniunideeadeatrecen revist ceea ce este actual n domeniul comerului electronic. Lista a fost limitat la acele metode care pot fi utilizate ntr-un context multinaional. Securitatea aplicaiilor WWW n comerul electronic Pagina 11 / 55 Au fost luate n considerare dou categorii mari de standarde: MetodedetransferdigitalalbanilorMetodedeafaceplielectronice,dac receptorul primete un semnal care poate fi folosit pentru viitoarele tranzacii.Protocoaledetranzaciielectronicesecurizateprotocoaleprincareplilesefac printr-o a treia parte (ex. banc, companie de credit carduri). Aceste protocoale acoper forma prin care se transmit mesajele i nu metodele utilizate pentru a asigura caracterul privat al mesajului. 1.4.1CEPS - Common Electronic Pursue Specifications UnstandardimportantdiscutatmaindetaliuesteCEPS.CommonElectronicPursue Specifications(CEPS)urmretesacopereimplementareaunuiportofelelectronicglobal interoperabil [39].CEPS este un standard gratuit. Cu toate acestea participanii la schema CEPS pot cere taxe pentru utilizarea unor anumite implementri specifice.Specificaiile tehnice CEPSau nevoie s fie combinate cu specificaiile schemei implementatorului pentru a crea specificaiile finale. Conform CEPSCO, organizaii din mai mult de 30 de ri, reprezentnd mai mult de 90% dinportofeleleelectronicedepepiaauczutdeacordsimplementezeCEPS.VISAa publicatpropriasaspecificaiedeCEPScunoscutsubnumeledeVCEPS-VisaCommon Electronic Pursue Specifications. 1.4.2Alte standarde n acest capitol s-au trecut n revist alte standarde n domeniu: EEP - European Electronic Pursue EMV - Integrated Circuit Card (ICC) Specifications for Payments Millicent Mpay NewGenPay Micropayment Wallet BIPS Bank Internet Payment Systems ECML - Electronic Commerce Modeling Language HBCI - Homebanking Computer Interface OFX - Open Financial Exhange Web Micropayments Common Markup for Micropayments Per-Fee-Links Securitatea aplicaiilor WWW n comerul electronic Pagina 12 / 55 C Ca ap pi it to ol lu ul l. . 2 2 P Pr re ez ze en nt ta ar re ea ar rh hi it te ec ct tu ur ri is so of ft tw wa ar re e d di is st tr ri ib bu ui it te e Obiectivul acestui capitol a fost s ofere o descriere succint a urmtoarelor arhitecturi software distribuite: sisteme 2-tier, 3-tier, ntier, arhitecturi distribuite web. 2 2. .1 1A Ar rh hi it te ec ct tu ur ri i 2 2- -t ti ie er r Arhitecturile2-tiersuntcelemaisimplearhitecturidistribuite.Sistemeledezvoltatepebaza acestorarhitecturisuntcompusedintreicomponente,componentedistribuitepedounivele: nivelulclient(nivelulcareutilizeazserviciile)inivelulserver(nivelulcareestefurnizorde servicii).Cele trei componente sunt: Interfaa utilizator componenta care permite utilizatorului interaciuneacusistemul,componentaprincareutilizatorultrimitecererisistemuluiiprincare utilizatorulprimeterezultatelecererilorlui;Componentadelogic(businesslogic) componentacareimplementeazlogicaaplicaiei;Modululdeaccesladate(persistena) modulul care interacioneaz cu datele (baza de date sau sistemele de fiiere) 2 2. .2 2A Ar rh hi it te ec ct tu ur ri i s so of ft tw wa ar re e 3 3- -t ti ie er r n comparaie cu arhitecturile software 2-tier, arhitecturile software 3-tier au un nivel adiional de logic (al 3-lea nivel numit business logic level).Acest al 3-lea nivel (numit i nivelul middle tier) este localizatntreniveluldeinterfa grafici niveluldegestiune aldatelor.La acestnivelse execut logica aplicaiei. 2 2. .3 3A Ar rh hi it te ec ct tu ur ri i d di is st tr ri ib bu ui it te e w we eb b Dincencemaimulteaplicaiisoftwaresuntdezvoltatecaisoluiiweb.Aceastapentruc soluiilewebauoseriedeavantajecomparativcusoluiilecareimplicoaplicaieinstalatpe computer. Aceste avantaje sunt legate n principal de uurina de a implementa la clieni o astfel de soluie prin instalarea ntr-o singur locaie.Cu noua ascensiune a soluiilor Web2.0 precum icucreterea capacitiide comunicaresepoatespunecsoluiile websuntdince n ce mai rspndite. 2 2. .4 4P Po oz zi i] ]i io on na ar re ea a r re e] ]e el le ei i n n a ar rh hi it te ec ct tu ur ri il le e d di is st tr ri ib bu ui it te e n cadrul arhitecturilor distribuite putem discutade urmtoarele tipuri de poziionare a conexiunii de reea relativ la nivelele aplicaiei software: GUIGraphicalUserInterfacedistribuit,esteatuncicndniveluldeprezentareeste distribuitpestereea.Interfaagraficestesituatpeomaindararelegturcu maina de server. Aici putem discuta de aplicaiile gen terminal prin care ne conectm la un server remote. Prezentareremote,atuncicndniveluldeprezentare/interfaagraficseexecutpeo main iar restul se execut pe server. Nu exist logic pe partea de GUI doar partea de prezentare grafic. Aplicaie distribuit, n condiiile n care interfaa grafic se afl pe o main mpreun cu o parte din logica de business i restul logicii de business se afl pe server. Dateremote,ncondiiilencareserveruldebazededateesteremote(arhitecturile2 tier) i aplicaia conine att partea de interfa grafic, ct i partea de business. Vorbim n aceste condiii de fat client. Datedistribuite,vorbimncondiiilencarebazadedateestedistribuitpestereea.Aplicaia n sine nu trebuie s tie unde sunt localizate datele. Securitatea aplicaiilor WWW n comerul electronic Pagina 13 / 55 2 2. .5 5S Se ec cu ur ri it ta at te ea a n n a ar rh hi it te ec ct tu ur ri i d di is st tr ri ib bu ui it te e Unaspectimportantndezvoltareasistemelorsoftwaredistribuiteesteaspectuldesecuritate. Securitatea este vzut ca un avantaj n cazul sistemelor distribuite. Acest capitol a fost dedicat prezentrii aspectelor de securitate n sisteme distribuite trecnd n revist urmtoarele; Autentificarea utilizatorilor -presupune c fiecare utilizator care va accesa sistemul s fie autentificat n sistem.Autorizarea operaiilor - presupune ca fiecare operaie din sistem s fie autorizat.Asigurarea unei comunicri securizate peste un canal nesigur. Auditareaaciunilor-implicnregistrareatuturoraciunilorutilizatorilorcaretrebuie urmrite din punctul de vedere a politicii de securitate. 2 2. .6 6P Pr re ez ze en nt ta ar re e t te eh hn no ol lo og gi ie e J Ja av va ainnd cont c dezvoltarea framework-ului s-a fcut folosind tehnologia Java, acest capitol a fost dedicat unei scurte prezentri a acestei tehnologii i a modului de lucru cu aceasta. Java nu este numai un limbaj de programare, Java este un mediu de programare ce ofer utilizatorului cadrul necesariuneltelenecesaredezvoltriiaplicaiilorJava.Javaesteotehnologiecareofer suport dezvoltrii de aplicaii distribuite, independente de platform. Programele Java pot rula pe diferitetipurideplatforme,cucondiiacasexisteinstalatomainvirtualJavadeasupra platformei respective. 2.6.1Dezvoltarea i execu]ia unei aplica]ii Java. Procesul de creareailansarenexecuie a uneiaplicaiiJavaimplic mai multe operaii.Vom ncercasdelimitmetapeleobligatoriidedezvoltareiexecuieauneiaplicaiiJavastand-alone. Acestea sunt: scrierea codului, compilarea, interpretarea i lansarea n execuie. 2.6.2Dezvoltarea i execu]ia unui applet Java. CreareaunuiappletJavasedeosebetedeceaauneiaplicaiiJava.Unadindifereneeste legatdestructuraprogramului.Spredeosebiredeaplicaie,applet-ulJavaseexecutn contextul unui browser WWW ce este compatibil Java.2.6.3Arhitectura sistemului Java Structura mainii virtuale Java (Java V|rtua| Hach|ne -JVH) este prezentat n urmtoare figur: Fig. 1. Structura mainii virtuale Java Bytecode Verifier Class Loder Interpretor Java RunTime Compilator JIT Garbage Colector Security Manager Sistemul de operare Hardware Securitatea aplicaiilor WWW n comerul electronic Pagina 14 / 55 C Ca ap pi it to ol lu ul l. . 3 3 A Au ut te en nt ti if fi ic ca ar re ea a n n s si is st te em me e s so of ft tw wa ar re e Unadintrecaracteristicileimportantealeorcruisistemdesecuritateesteautentificarea.Acest capitolprezintaspectelegatedeautentificareansistemesoftwarediscutnddiferitetipuride autentificriprecumiprincipiicarestaulabazaacestora.Autentificareaesteprocesulde confirmareaidentitiiunuiutilizatorsauprocesulprincaresedemonstreazcunutilizatorB acioneaz n numele unui utilizator A n cazul n care a fost delegat de ctre utilizatorul A. 3 3. .1 1C Cl la as si if fi ic ca ar re e a au ut te en nt ti if fi ic ca ar re e Exist trei tipuri de baz pentru autentificare[24]: Autentificarea unilateral autentificarea se bazeaz pe faptul c doar una dintre pri se autentific fa de cealalt;Autentificaremutualautentificareaimplicfaptulcambelepriseautentific reciproc Autentificare mediat autentificarea implic o a treia parte, numit mediator, prin care se autentific cele dou pri. Ambele pri au ncredere n mediator. Cele trei forme de autentificare sunt descrise n urmtoarea figur: Fig. 2.Tipuri de autentificare Ca i mecanisme de realizare a autentificrii putem enumera urmtoarele: Parol:utilizatorulAtrimiteserviciuluiBoperecheunic(nume,parol)pecareBo recunoate. Secret cunoscut de ambele pri algoritmi de criptare cu cheie secret: autentificarea se bazeaz pe un secret K pe care doar A i B l cunosc. Autentificarea se face n aa fel nct secretul nu va fi dezvluit. Semntur algoritm de criptare cu chei publice:Utilizatorul A semneaz un document folosindcheiasaprivatpecarecealaltpartenuocunoate.ServiciulBrecunoate semntura folosind cheia public a lui A. Deasemeneanacestcapitols-afcutoprezentareapescurtaacestormecanismede autentificareprecumiuneleobservaiilegatedeacesteaviznddescrierealor,avantajei dezavantaje, variante de mbuntire, etc.Autentificare mediat (3) Autentificare unilateral(1) Utilizator A Dovad A Serviciu B Autentificare mutual (2) Utilizator A Dovad A Serviciu B Dovad B Cerere A Cerere A Utilizator A Serviciu B Cerere A Mediator Dovad ADovad B Securitatea aplicaiilor WWW n comerul electronic Pagina 15 / 55 Oaltclasificareaautentificriiidentitiiunuiutilizatorsepoatefacenfunciedemodalitatea prin care utilizatorul interacioneaz cu sistemul: Ceea ce utilizatorul cunoate (o parol, un numr de identificare) Ceea ce utilizatorul are (un token de securitate, un smart card) Ceeaceutilizatoruleste(ocaracteristicfizicautilizatoruluibiometric,amprent digital, de retin, etc.) Fiecaredinceletreimecanismedeautentificareaudezavantaje,aacrecomandareaeste utilizareaadoumecanismeseparatempreun.Totuidatoritfaptuluicimplementareaa dou metode de autentificare implic costuri adiionale de hardware i de infrastructur cele mai multe sisteme folosesc o singur metod i cel mai des cea bazat pe parol. 3 3. .2 2D De el le eg ga ar re ea a O problem legat de autentificare este problema delegrii.Mai exact utilizatorii trebuies aib posibilitateadeadelegaanumitorcomponente/sistemesoftware,efectuareaoperaiilorn numelelor.nprivinadelegriitrebuieconsideratdelegareaspecificprincareutilizatorul deleagdoarunsetlimitatdeaciuniautorizndastfelexecuiadeaciunispecifice.De asemenea,pentruamicorarisculcaoaplicaiedelegatsfiecorupt,esterecomandatca delegarea s fie limitat la o anumit perioad de timp.3 3. .3 3M Me et to od de e a av va an ns sa at te e d de e a au ut te en nt ti if fi ic ca ar re e Acest capitol a prezentatmetodologii noi de autentificare [22]. Orice aplicaie modern trebuie s fieflexibilnceeaceprivetetehnologiileactualedeautentificarepede-oparteispermit integrarea ulterioar a viitoarelor tehnologii de autentificare pe de alt parte. Celemainoimetodedeautentificaresuntcelebazatepeatributelebiologicealeutilizatorilor (biometrics). Autentificarea biometric se refer la identificarea automat a unei identiti bazat pe verificarea unei caracteristici fizice umane saua unei caracteristici comportamentale, cum ar fi:amprentadigital(fingerprint),geometriaminii,retina,formairisului,trsturifaciale, semnturasautimbruvocal.Indiferentdetehnologiapecaresebazeaz,implementareaunui sistem de autentificare biometric, are dou faze principale: Fazadenregistrareautilizatorilor:naceastfazsistemulnvacaracteristicile biometricealeutilizatorilor.Aceastfazsecompunedinachiziionareadatelori asocierea lor identitilor. Fazadeautentificareautilizatorilor:naceastfazsistemulcompardatele prezentate spre autentificare de ctre un utilizator cu cele salvate n prima faz. Securitatea aplicaiilor WWW n comerul electronic Pagina 16 / 55 C Ca ap pi it to ol lu ul l. . 4 4A Au ut to or ri iz za ar re ea a n n s si is st te em me e s so of ft tw wa ar re e 4 4. .1 1D De ef fi in ni ir re e Autorizarea este procesul prin care se acord unui utilizator sau unui sistem permisia de a face saude a obine ceva. Controlul accesului este mijlocul prin care aceast permise esteacordat explicitsaunuesteacordat.nmodlogicautorizareaesteprecedatdeautentificare. Autorizareapoateluadiferiteforme.Astfelc,prinautorizarenudoarcseverificdac utilizatorul are acces la resurse dar se i verific dac la un moment dat de timp utilizatorul poate accesa resursa, precum i dac pentru accesul ei a urmat o anumit cale.4 4. .2 2M Mo od de el le e- -p po ol li it ti ic ci i d de e c co on nt tr ro ol l a ac cc ce es s Tehnologiiledecontrolaleaccesuluiauevoluatde-alungultimpuluiisecunoscmaimulte modele de control access. n ideea aceasta n acest capitol s-au discutat urmtoarele modele: AccessControlListACL:Aceastmetodpresupunecfiecareresursaunui sistemsoftwareareasociatolistdeutilizatoricareaudreptulsaccesezeresursa respectiv. DACDiscretionaryAccessControl:Reprezintunmodeldeacces,opoliticde accesdeterminatdeproprietarulunuifiierorialalteiresurse.Proprietarulresursei respectivedecidecinearesaucinenuaredreptuldeaaccesaresursarespectiv precum i ce drepturi are legate de utilizarea ei (citire, scriere, etc.). MAC -Mandatory Access Control: Reprezint un model de acces, o politic de acces determinat de sistem i nu de proprietarul resursei. Cea mai important caracteristic a MAC implic restricionarea controlului absolut la resurse pentru utilizatorii care creeaz aceste resurse.RBAC Role BasedAccess Control:n cadrul RBAC, deciziiledeaccessunt bazate pe roluri pe care utilizatorii individuali le au n cadrul organizaiilor. 4 4. .3 3R RB BA AC C n continuare, ne-am oprit asupra modelului de baz pentru sistemul nostru, i anume modelul de accescontrolbazatperoluri(Role-BasedAccessControlRBAC)[13].ncadrulRBAC, deciziile de acces sunt bazate pe roluri pe care utilizatorii individuali le au n cadrul organizaiilor. n aceast idee un utilizator are acces pe baza acelor roluri care isunt asignate n organizaie.Drepturile de acces sunt grupate pe un anumit rol i accesul la resurse este restricionat pentru utilizatorii care au rolul respectiv. n cadrul RBAC, utilizatorilor li se acord un anumit rol bazat pe competeneleiresponsabilitilentr-oorganizaie.Operaiilepecareunutilizatorlepoate executasuntbazateperolurilepecareacestalearencadrulorganizaiei.Apartenenaunui utilizator la un rol poate fi acordat sau revocat uor, n funcie de cerinele de business. Astfel, se simplific administrarea i gestiunea privilegiilor prin faptul c se pot actualiza uor privilegiile asociate unui rol fr schimbarea privilegiilor pentru fiecare utilizator. O ierarhie de roluri definete rolurile i atributele lor specifice precum i relaiile de apartenen a unorrolurilaaltele.Astfelunrolpoatecuprindemaimulteroluri.Carezultatasignareaunui utilizator la un rol acord utilizatorului toate permisiile pe care rolul asignat le are, precum i toate permisiileasignaterolurilorcareierarhicseaflsubrolulrespectiv(urmrindarborelede alocare).ModelulRBACesteorganizatnpatrucomponenteRBACcareaufostdiscutatenaceast seciune.Acestemodelesunt[14]:ModeluldebazRBAC-CoreRBAC,Modelulierarhic RBACHierarchicalRBAC,SSDRBACStaticSeparationofDutyRelations,DSDRBAC Dynamic Separation of Duty Relations. Securitatea aplicaiilor WWW n comerul electronic Pagina 17 / 55 4 4. .4 4M Mo od de el lu ul l d de e b ba az z R RB BA AC C. .Acest model conine aspectele eseniale ale RBAC [14]. Conceptele de baz sunt celedescrise anterior,maiexactfaptulcutilizatoriisuntasignailaroluri,permisiilesuntasignatelarolurii utilizatoriiauanumitepermisiidatoritfaptuluicsuntmembriiunuirol.CerineleRBAC presupun c asignrile de utilizator-rol i cele de permisii-rol pot fi de tipul many-to-many. Astfel aceluiaiutilizatoripotfiasignatemaimulteroluriiarunrolpoateaveamaimuliutilizatori asignailui.Deasemenea,acelailucruestevalabilipentrupermisii,maiexactopermisie poatefiasignatmaimultorroluriiunuirolipotfiasignatemaimultepermisii.Cerinele modeluluidebazRBACacoperiparteadeauditare.Astfelestenecesarposibilitatea determinriituturor rolurilor asignateunuiutilizator precumia tuturor utilizatorilorasignaiunei anumitepermisii.Oaltcerinmaiavansatpeparteadeauditareestedeterminareatuturor permisiilor asignate unui rol precum i a tuturor rolurilor care au o anumit permisie.Modelul de bazRBACincludeiconceptuldesesiuneutilizator/subiect,carepermiteactivareai dezactivarea selectiv a rolurilor ntr-o sesiune. De asemenea, modelul de baz presupune faptul c utilizatorii pot folosi simultan permisiile din mai multe roluri care le sunt asignate. Fig. 3.Modelul de baz RBAC 4.4.1Defini]iile matematice ale modeluluiRBAC de baz nvedereadefiniriimatematiceamodeluluidebazRBACconsidermdefiniteurmtoarele mulimi de elemente[13]: USERS=mulimeadeutilizatori,ROLES=mulimeaderoluri,OPS=mulimeade operaii, OBS = mulimea de obiecte, SUBJECTS = mulimea de subiecincontextulmulimilordefiniteanteriormodeluldebazRBACpoatefidefinitdupcum urmeaz: , ROLES USERS UA reprezint mulimeade mapri utlizator-rol, maparede tipul many-to-many" Securitatea aplicaiilor WWW n comerul electronic Pagina 18 / 55 , 2 ) : ( : _USERSROLES r users assigned rolul r este mapat la o mulime de utilizatori } ) , ( | { ) ( UA r u USERS u r sers assigned_u =) (2OBS OPSPRMS= ,definete mulimea de permisii ROLES PRMS PA ,reprezint mulimea de mapri permisii-roluri, mapare de tipul many-to-many PRMSROLES r s permission assigned 2 ) : ( _ , maparea rolului r la un set de permisii } ) , ( | { ) ( _ PA r p PRMS p r s permission assigned =USERS SUBJECTS s users subject ) : ( _ ,mapareaunuisubiectslautilizatorul asociat subiect-ului ROLESSUBJECTS s roles subject 2 ) : ( _ , maparea unui subiect s la un set de roluri } ), ( _ ( | { ) ( _ UA r s user subject ROLES r s roles subjecti i 4 4. .5 5M Mo od de el lu ul l i ie er ra ar rh hi ic c R RB BA AC C. .Acestmodelconineaspecteledinmodeluldebazlacareseadaugcaracteristicileprincare ofer suport pentru ierarhii de roluri[13]. Astfel un rol poate conine mai multe roluri cu o ierarhie de roluri prini i roluri copii. Conform conceptului, un rol printeva moteni toate permisiile pe care le au rolurile copii.Acest model cunoate dou tipuri de ierarhii: Ierarhie general RBAC General Hierachical RBAC. n acest caz relaiile ntre prini i copii sunt arbitrare. De exemplu, un copil poate s aib mai muli prini. Ierarhie limitat RBAC Limited Hierachical RBAC.Acest tip impune anumite restricii ndefinireaierarhiilorderoluri.Celemaidesutilizatemodeledelimitaresuntpebaza structurilor simple de arbore sau arbore inversat. 4.5.1Defini]iile matematice ale modeluluiRBAC ierarhic n contextul mulimilor definite anterior modelul de baz RBAC poate fi definit dup cum urmeaz [14]:ROLES ROLES RH este o ordonare parial a mulimiiROLES numit relaie de motenire,definitprin,unde 2 1r r ,doardactoatepermisiileroluluir2suntde asemenea permisii ale rolului r1 i dac toi utilizatorii rolului r1 sunt i utilizatori ai roluluir2. Matematic acest lucru se poate defini astfel: ) ( _ ) ( _) ( _ ) ( _2 11 2 2 1r users authorized r users authorizedr s permission authorized r s permission authorized r r ,unde USERSROLES r users authorized 2 ) : ( : _ ,reprezintmapareaunuirolrlao mulime de utilizatori n prezena unei ierarhii de roluri. Matematic aceasta poate fi scris astfel: } ) , ( , | { ) ( _' 'UA r u r r USERS u r users authorized =PRMSROLES r s permission authorized 2 ) : ( : _ , reprezintmapareaunuirol rla o mulime de permisiin prezena unei ierarhii de roluri. Matematic aceasta poate fi scris astfel: } ) , ( , | { ) ( _' 'PA r p r r PRMS p r s permission authorized =Securitatea aplicaiilor WWW n comerul electronic Pagina 19 / 55 4 4. .6 6M Mo od de el lu ul l S SS SD D R RB BA AC C. .ModelulStaticSeparationofDutySSDesteunmodelcarepermitecontrolulconflictelorde interes[13].ntr-unsistembazatperoluri,unconflictdeinteresapareatuncicndunutilizator primeteautorizareapentrupermisiiasociatenroluriconflictuale.Omodalitatedeprevenireaacestei formedeconflictde interesesepoate face prinseparareastaticaresponsabilitilor staticseparationofdutySSD,separarecareforeazaplicareaunorconstrngeriodatcu asignarea utilizatorilor la roluri. Cel mai simplu caz este constrngerea prin care dou roluri sunt mutual exclusive. Fig. 4.Modelul SSD - RBAC cu ierarhie de roluri innd cont de posibilitatea de a avea roluri ierarhice, SSD poate fi definit n cele dou contexte diferite (cu sau fr ierarhie de roluri):SSDfrierarhiederoluri.nacestcazsedefinescconstrngeripentruasignarea utilizatorilorlaroluri.Astfel,odatceunutilizatorestemembrualunuirolacestapoate mpiedica utilizatoruls fie membrualaltui rolsaualtor roluri, depinznd deregulilepe care SSD le foreaz. SSD cu ierarhie de roluri. nacest caz, n plus fa decazul anterior apare implicarea ierarhiei de roluri n constrngeri. Astfel, n momentul n care se verific constrngerile se iau n calcul att rolurile asignate ct i cele din ierarhia de motenire.4.6.1Defini]iile matematice ale modeluluiRBAC - SSD Definiia matematic pentru RBAC SSD fr ierarhie de roluri poate fi formalizat astfel [13]: Dacseimpunesepararea static pentruoricaredou perechideroluri 1ri 2ratunci 1ri 2rnu pot avea n comun utilizatori asignai la aceste roluri. Securitatea aplicaiilor WWW n comerul electronic Pagina 20 / 55 ) 2 ( N SSDROLES este o colecie de perechi) , ( n rsn SSD unde fiecare rseste un setderoluriinesteunnumrnatural2 ,cuproprietateacniciunutilizatoreste asignat la un nsau mai multe roluri din fiecare set rs.SSD n rs ) , ( .

s rr users assigned n s rs s SSD n rs = ) ( _ : , ) , (ncazulRBAC-SSDnprezenauneiierarhiimodelulesteredefinitconsiderndmaidegrab utilizatorii autorizai dect cei asignai. Formal aceasta poate fi definit astfel:

s rr users authorized n s rs s SSD n rs = ) ( _ : , ) , (4 4. .7 7M Mo od de el lu ul l D DS SD D R RB BA AC C. .ModelulDynamicSeparationofDuty-DSD,esteunmodelcareasemeneamodeluluiSSD limiteazpermisiiledisponibileutilizatorului.DSDlimiteazpermisiilencontextulrolurilorcare pot fi activate n timpul unei sesiuni de ctre utilizator. Ca i n cazul SSD i n cazul DSD putem definioconstrngereasemeneauneiperechi(setderoluri,n)careareproprietateacun utilizatornupoateactivansaumaimulteroluridinsetulderoluripentruoanumitsesiune. Definiia matematic pentru RBAC DSD poate fi formalizat astfel [13]: Dac se impune separarea dinamic pentru oricare dou perechi de roluri 1ri 2ratunci 1ri 2rnu pot avea n comun utilizatori autorizai. ) 2 ( N DSDROLES este o colecie de perechi) , ( n rsn DSD unde fiecare rseste un set de roluri i n este un numr natural2 , cu proprietatea c nici un subiect nu poate activa nsau mai multe roluri din setul rs n fiecare setDSD dsd . , 2 ) , ( , , 2 n rs n DSD n rs N n rsROLES i n subset role s roles subject subset role rs subset roleDSD n rs N n subset role rs SUBJECTS sROLES ROLES