Metodologija naucnog i strucnog rada DOI: N/A

Bezbednost Servisno Orjentisane Arhitekture

Aleksandar NedeljkovicMatematicki fakultet, Studentski Trg 16

11000 Beograd, Srbijami09036@alas.matf.bg.ac.rs

Sazetak: Servisno Orjentisana Arhitektura (SOA) je jedan od napopularni-jih koncepata za implementiranje racunarskih sistema. Medjutim suocava sesa velikim bezbednosnim izazovima i mnogim standardima koji pruzaju sigu-rnost. U ovom radu diskutovacu o bezbednosnim rizicima Servisno Orjenti-sane Arhitekture koji su povezani sa vaznim aspektima sigurnosti kao sto suautentifikacija, autorizacija, poverljivost, integritet i neporecivost. Takodje cupredstaviti mehanizme koji se koriste od strane pruzaoca usluga za resavanjesigurnosnih problema.

Kljucne reci: Sigurnost, Servisno Orjentisana Arhitektura (SOA), Kerberos,Infrastruktura javnog kljucca (PKI), WS-Security, XML Digitalni potpis, SAML,XACML

1. Uvod

Servisno Orjentisana Arhitektura (SOA) jejedan od najpopularnijih IT trendova, kojije definisan na sledeci nacin: Servisno Orje-ntisana Arhitektura (SOA) je dizajn obrazackoji se sastoji od labavo spregnutih, vidljivih,visekratnih interoperabilnih platformskih uslu-ga u kojima je svaka usluga dobro definisanstandard. Svaka od ovih usluga moze bitivezana ili nepovezana u bilo koje vreme i popotrebi [5]. Medjutim, kao sto je definisano,SOA ima labavo spojenu funkciju , koja ciniSOA-u otvorenom na bezbednosne izazove.To znaci da SOA mora da ispuni nekoliko za-hteva. Glavni zahtevi su pretrazivost servisa,autentifikacija servisa, provera identiteta ko-risnika, kontrola pristupa, poverljivost, in-tegritet, dostupnost i privatnost. Da bise obezbedila sigurnost u labavo vezanomSOA okruzenju, zajednica otvorenih stan-darda koja je kreirala veb servise razvilaje niz bezbednosnih standarda, sto je jedanod najaktivnijih i siroko prihvacenih imple-mentacija Servisno Orjentisane Arhitekture.

Usluge su opisane na jeziku standardne defini-cije, imaju objavljen interfejs i komunicirajujedni sa drugima trazeci izvrsenje svojih ope-racija kako bi kolektivno podrzali zajednickiposlovni zadatak ili proces [4].

SOA je metodologija za postizanje inter-operabilnosti aplikacija i ponovne upotrebeIT sredstava koje karakterisu jak arhite-ktonski fokus na idealnom nivou apstrakci-je, postavljanje infrastrukture i bibliotekaza visekratnu upotrebu (W3C definicija) [1].Ona takodje obuhvata podrsku za organizo-vanje i koriscenje resursa koji su pod kontro-lom razlicitih administracija.

Neophodno je vreme da preduzeca brzoreaguju na poslovne promene sa efikasnoscu iprednostima postojecih ulaganja u aplikacijei aplikacije infrastrukture za resavanje novijihposlovnih zahteva. Resenje koje se aktivnokoristi za resavanje ovih zahteva je ServisnoOrjentisana Arhitektura koja omogucava pre-duzecima da prikljuce nove usluge ili nado-gradnju postojecih usluga u zrnasti nacin zaobradu novih poslovnih zahteva. SOA pruzamogucnost da se usluge koriste preko ra-

1

zlicitih kanala i otkriva postojeca preduzecai njihove aplikacije kao usluge, sto je osnovnigradivni blok Servisno Orjentisane Arhite-kture.

2. Sigurnosni problemi

Priroda SOA-e cini sisteme podloznijimbezbednosnim pretnjama zbog sledecih ra-zloga.

1. Servisi mogu na primer da daju pristupdesktop aplikaciji i neke aplikacije kojenormalno ne bi bile dostupne kli-jentu zbog servisnog interfejsa su javnoizlozene celom svetu. Vlasnik ima naj-manju kontrolu ko moze da koristi us-lugu.

2. Podaci su izlozeni sirokom spektrukorisnika. Zastita podataka tokomtranzita i skladistenja je vazna zbogobezbedjivanja integriteta podataka iprivatnosti.

3. Podaci putuju kroz heterogene sredine,imajuci razlicite politike, tehnologije imrezne protokole. Stoga je tesko in-tegrisanje i udruzivanje razlicitih merabezbednosti za implementaciju.

4. Povezivanje kod Servisno OrjentisaneArhitekture nije od tacke do tacke (eng.”point-to-point”)

5. Ovaj sistem je osetljiv na ponovnenapade koji jednostavno ponavljajuvazecu potpisanu poruku i dobijajuneovlasceni pristup.

2.1. Sigurnosna pitanja

Osnovna pitanja bilo koje bezbednosne in-frastrukture su autentifikacija, autorizacija ipoverljivost. Fokus se prosiruje tamo gde suinfrastrukture izlozene kao u slucaju SOA-e.U ovom slucaju to su problemi neporecivostii integriteta poruke.

1. Autentifikacija − Predstavlja proveruvalidnosti identiteta subjekta. Subjekatmoze biti korisnik, veb servis, racunarili aplikacija. Autentifikacija je prvikorak u kontroli prava pristupa. Dabi se omogucila kontrola prava pris-tupa neophodno je da sistem identi-fikuje subjekat i da poseduje izvestannivo uverenja u autenticnost identitetasubjekta. Medjusobna autentifikacijapredstavlja dvosmernu autentifikaciju iomogucava dokazivanje identiteta obestrane ukljucene u komunikaciju.

2. Autorizacija − Predstavlja odredji-vanje prava i dozvola koje korisnik pose-duje. Nakon autentifikacije, provereidentiteta, sistem mora odrediti pravakoja korisnik poseduje i koje su nje-gove mogucnosti koriscenja sistemskihresursa.

3. Poverljivost − Posto se podaci delepreko razlicitih usluga i preko razlicitihdomena postoje velike sanse da su po-daci izlozeni nezeljenim primaocima up-rkos strogim merama zastite podatka.

4. Integritet − Validnost integriteta po-dataka predstavlja tehnologiju dokazi-vanja da poruka nije menjana odstrane neautorizovanog subjekta. Zbogmogucnosti zloupotreba poruka prekoTCP/IP mreza neophodno je koris-titi digitalne potpise, autentifikacionekodove ili hash algoritme da bi sepotvrdila validnost integriteta poruke.

5. Nemogucnost poricanja − Posledicadigitalnog potpisivanja poruke i pred-stavlja legalni dokaz da je subjekat pot-pisao poruku. Digitalni potpis krip-tografski vezuje identitet potpisivacasa sadrzajem potpisanih podataka.Koriscenje kriptografije javnim kljucemomogucava neoporecivost posiljaoca daje on potpisao poruku.

2

2.2. Tehnologija koja narusava SOAbezbednost

SOA je pod uticajem primene ranjivostiVeb aplikacija koje su obicno izgradjene navrhu veb protokola. Klasicne bezbednosneranjivosti su one koje se mogu iskoristiti bezupotrebe novijih veb tehnologija. Predstavicuneke od uobicajenih veb bezbednosnih pro-pusta koji uticu na SOA aplikacije.

1. SQL injekcije − omogucavaju na-padacu da izvrsava neautorizirane SQLupite iskoristavajuci neproveravanjeulaza u veb aplikacijama koje gradedinamicke SQL upite. Ranjivost jeprisutna kod korisnickog unosa koji senekorektno proverava.

2. XML Spoljasnji Unos − DTDfunkcionalnost koja je dostupna u XML-u se koristi za definisanje sintakse el-emenata dokumenata. On takodjeomogucava spoljasnjim podacima dabudu ugradjeni u XML dokument.Navodjenjem lokalnog fajla, neke XMLfunkcije mogu biti napravljene zaomogucavanje neovlascenog pristupa in-formacijama iz lokalnog fajl sistema.

3. XML napad uskracivanjem us-luga(eng. Denial of Service) − Ovajnapad koristi prednost povlacenja uentitete koji su definisani u DTD-u. Povlacenje entiteta rekurzivnoizaziva crpljenje memorije i na taj nacinonemogucava servis da obradjuje daljezahteve.

4. Ponovni napadi (eng. Replay at-tacks) − SOA je zasticena politikamakoje obezbedjuju digitalno potpisanezahteve servisa. Ovaj sistem je ranjiv naponovne napade koji jednostavno pon-avljaju validno potpisanu poruku cimese dobija neovlasceni pristup.

3. Postojeca resenja SOAbezbednosti i njihove kri-tike

Mere bezbednosti su dizajnirane i prime-njuju se za razlicite aspekte bezbednosti (kaosto je pomenuto u odeljku 2). Najkoriscenijii najsveobuhvatniji mehanizmi koji se baveSOA bezbednoscu su Kerberos i Infrastru-ktura javnog kljuca (PKI).

3.1. Infrastruktura javnog kljuca

Infrastruktura javnog kljuca (PKI) je skuphardvera, softvera, ljudi, polisa i proceduraneophodnih za kreiranje, upravljanje, dis-tribuiranje, koriscenje, skladiscenje i pozi-vanje digitalnih sertifikata. Bazira se na krip-tografiji javnog kljuca za enkripciju. PKIkreira digitalne sertifikate koji mapiraju javnekljuceve u entitete, sigurno skladisteci te ser-tifikate u centralni repozitorijum i poziva ihpo potrebi.

Slika 1. Tok podataka infrastrukture javnogkljuca (PKI)

PKI tok podataka [3] [2] [1]Korak 1 − Korisnik omogucava akreditiveCertification Authoriti-ju (CA) i zahteve zasertifikat

Korak 2 − Certification Authoriti (CA) kon-taktira Registration Authority (RA) da biproverio korisnicke akreditive. Ukoliko je ko-risnik autenifikovan (RA) ga prosledjuje (CA)za izdavanje sertifikata.

3

Korak 3 − Certification Authoriti (CA)obuhvata probleme korisnikovog javnog kljucai rok upotrebe sertifikata.

Korak 4 − Korisnik predaje sertifikatpruzaocu usluge dok zahteva uslugu

Korak 5 − Pruzaoc usluge verifikuje serti-fikat i ako je sertifikat validan zapocinje sekomunikacija

Infrastruktura javnog kljuca (PKI) sebavi vecinom bezbednosnih izazova kojenamece SOA kao sto su provera identiteta,poverljivost, integritet i neporecivost.

3.1.1. Slabosti infrastrukture javnogkljuca (PKI)

1. PKI je tehnika koja zahteva mnogoresursa u smislu procesorskog vremena imemorije pa se ne moze lako integirsatina uredjajima slabe snage koji imajumogucnost povezivanja na internet kaosto su mobilni telefoni

2. PKI se ne bavi ovlascenjem korisnika zaizvrsavanjem odredjene radnje ili pozi-vanje servisa

3. Svaki sajt ukljucuje poverenje u svojekorisnike i u sertifikate za ovlascenja.Ukoliko poverenje izmedju bilo koga odnjih ne postoji tada uticaj toga mozebiti potencijalno opasan.

3.2. Kerberos

Osnovnu verziju Kerberosa je formiraoMIT (Massachusetts Institute of Technol-ogy). Do danas se pojavilo vise verzijaovog protokola, a najpopularnije su MITverzija 4 i verzija 5. MIT je projek-tovao Kerberos da zastiti mrezne serviseomogucene od strane projekta Atina. Zas-novan je na ranijem Needham-Schroeder pro-tokolu simetricnih kljuceva. Protokol je naz-

van po bicu Kerberos iz grcke mitologije kojije monstruzni troglavi cuvar Hada. Kerberoskoristi kriptografiju simetricnih kljuceva. Un-akrsna autentifikacija je korisna komponentaKerberos-a ciji je cilj da omoguci bezbedanpristup usluga preko organizacionih ciljeva.

Slika 2. Kerberos tok podataka

1. Korisnik salje akreditive Authentica-tion Service-u i zahteva Ticket GrantingTicket

2. AS verifikuje korisnika sa podacima.Nakon verifikacije generise se kljuc zasifrovanje i vreme isteka sesije kojenajcesce iznosi 8 sati. AS salje kljucsesije koji ce se koristiti izmedju koris-nika i TGS-a. Kljuc sesije se sifruje ko-risnikovim tajnim kljucem i TGS tajnimljucem pa se zatim salje korisniku.

3. Korisnik salje TGT i ID servisa kaTicket Granting servisu

4. TGS dekriptuje TGT i oporavlja sesijekljuca koji ce se koristiti sa klijentom ubuducoj komunikaciji

5. TGS generise kljuc sesije (Client-ServiceKey) koji ce se koristiti od strane kli-jenta za dalju komunikaciju sa servi-som. TGS sifruje to sa servisnim tajnimkljucem i salje nazad klijentu

4

6. Klijent salje sifrovani Service ticket (do-bijen od TGS-a) ka servisu i zahteva op-eraciju

7. Servis desifruje potvrdu i dobija kljucsesije. Taj kljuc se u buducnosti koristiza komunikaciju sa klijentom sve do is-teka sesije

Sigurnosna pitanja kojima se bavi Kerberossu autentifikacija, poverljivost i integritet.

3.2.1. Mane Kerberos protokola

1. Kerberos ne moze da se koristi u inter-akciji sa ne Kerberos sistemima

2. Postojeci servisi zahtevaju modifikacijuda bi rukovali Kerberos protokolom

3. Centar za distribuciju kljuceva mozebiti jedna od tacaka neuspeha. Ukolikoje ugrozen ceo Kerberos sistem je podrizikom

3.3. Sigurnosni standardi veb servisa

Postoji veliki broj standarda veb servisa,a ja sam se fokusirao na glavnim standa-rdima za koje smatram da su najvise vaznida bi se razumela SOA arhitektura. Osnovnibezbednosni ciljevi fokusiraju se na bezbed-nost poruke kao poverljivosti, integriteta iautenticnosti podataka koji su pokriveni odstrane tri osnovna bezbednosna standarda:WS-Security, XML Digitalnih potpisa i XMLEnkripcije.

3.3.1. WS-Security

WS-Security je predlozen kao standard odstrane Microsoft-a i IBM-a 2002. godine.Uspostavljen je kao OASIS standard 2004.Ovaj standard definise poboljsanja SOAPporuka u cilju obezbedjivanja sigurnosti uporukama koje se prenose izmedju korisnikai servisa. Zbog toga su dodatne informacijeukljucene u zaglavlju SOAP poruka na osnovu

daljih specifikacija kao sto su XML Enkrip-cija za poverljivost poruke, XML Digitalnipotpis za integritet poruke i jos mnogo toga.WS-Security je koriscen za primenu sirokogspektra ralicitih bezbednosnih tehnologija imodela kao sto su X.509 sertifikat i Kerberos.

Nedostaci WS-Security standarda

1. WS-Security koristi XML Digitalni pot-pis za potpisivanje ne susednih delovaSOAP poruka. Stoga su sva ogranicenjaXML Digitalnih potpisa takodje pri-menljiva i na WS-Security.

2. WS-Security omogucava vise bezbed-nosnih zaglavlja sa istim imenom uokviru iste SOAP poruke. Ovo stvaraveliki propust koji moze biti iskoriscenod strane napadaca.

3. WS-Security ne predlaze nikakvu novutehnologiju bezbednosti. Medjutimon navodi kako postojece bezbednosnetehnologije mogu da se iskoriste za sig-urnu razmenu SOAP poruka.

3.3.2. XML Digitalni potpis

XML potpis je deo W3C standarda kojiobezbedjuje integritet poruke i ne odbaci-vanje XML dokumenata i XML elemenata.XML potpis se ponekad naziva jos XML-SIG ili XML-DSIG. Oslanja se na tehnologijujavnih kljuceva u kojoj se hes elementi ili skupXML elemenata potpisuju privatnim kljucempotpisnika i stoga mogu biti proverene odstrane trecih lica obavljanjem kriptografskihoperacija na hes podatke sa javnim kljucemposiljaoca. NDA ugovori ( eng. Non-disclosure agreement) su relativno jednos-tavan nacin cuvanja poverljivosti informa-cija, ali potrebno je naglasiti da oni nesprjecavaju kradju informacije vec vlasnikuinformacije daju pravni oslonac za tuzbu uslucaju zloupotrebe. Poruka moze imati ele-mente koji su digitalno potpisani od strane

5

vise razlicitih strana, i potpis moze krip-tografski spojiti elemente. Moguce je spojitiidentitet, autorizaciju i vreme iz WS-securitynaslova i SOAP zahtev, ovim sprecavamo na-pade ponovnim koriscenjem istih poruka.

1 <Signature >

2 <SignedInfo >

3 <CanonicalizationMethod />

4 <Signature Method />

5 <Reference >

6 <Transforms >

7 <DigestMethod >

8 <DigestValue >

9 </Reference >

10 <Reference /> etc.

11 </SignedInfo >

12 <Signature Value />

13 <KeyInfo />

14 <Object />

15 </Signature >

Osnovna struktura XML Digitalnih potpisa

Nedostaci XML Digitalnih potpisa

XML reprezentuje podatke koriscenjemdrvolike strukture.XML Digitalni potpisiomogucavaju nepovezanim objektima XMLskupa podataka odvojeno potpisivanje. Pot-pisan objekat moze biti oznacen koriscenjemindirekcije (URI-ja) kao reference potpisanomelementu. Ovo indirektno referenciranje nedaje nikakve informacije o stvarnoj lokacijipotpisanog objekta.Dakle, potpisan objekatmoze biti lako premesten a da Signaturevalue i dalje ostaje na snazi. U slucajevimakada je lokacija objekta podataka vaznau tumacenju semantike podataka ovo mozeda bude iskorisceno od strane napadaca dastekne neovlascen pristup nad neovlascenimresursima. Ovo je glavno ogranicenje XMLDigitalnih potpisa.

3.3.3. SAML

SAML(The Security Assertion MarkupLanguage) je okruzenje bazirano na XML-ui koristi se za uspostavljanje autentifikacijei naziva subjekta kao i atributa informacije.

Koristi se u razne svrhe i obicno u kom-binaciji sa drugim standardima ukljucujuciWS-Security SOAP Messaging, WS-Trust,WS-Federation, XACML i ID-WSF(LibertyIdentity Web Services Framework). Ovajstandard se razvija oko koncepta tvrdnje(assertion), koji predstavlja izjavu o sub-jektu. Moze biti tvrdnja o autentifikaciji sub-jekta(identitet subjekta), spisku autorizaci-jskih prava subjekta ili izraz autorizacijskeodluke koja daje pristup nekom resursu. Pov-erenje u SAML tvrdnju je bazirano na pov-erenju u entitet koji zahteva tu istu tvrd-nju. Od usvajanja 2002. godine ovaj stan-dard je znacajno uznapredovao i sa verzijom2.0 pruza podrsku za federativni identitet.

Slika 3. je primer koriscenja SAML-a kao protokola za zahtev/odgovor (re-quest/response) u potraznji tvrdnji za od-luke o pravima pristupa. Pokazuje korscenjeSAML novcica u WS-Security i konceptualnuupotrebu SAML tvrdnji u browser-based SSOokruzenju [6].

Slika. 3 Korisnici SAML-a u SOApreduzecima

Vidimo tri tipa izjave u tvrdnji:

• Izjava autentifikacije − Pruza informacije otome kako, kada i od strane koga je izvrsenaautentifikacija subjekta

• Izjava atributa − Prikazuje spisak atributakoji se odnose na subjekat

6

• Izjava autorizacijske odluke − Koristi seza prikaz prava subjekta da pristupi odre-djenom resursu

SAML takodje definise zahtev/odgovor (re-quest/response) protokol za traznju tvrdnji,obicno se koristi za autorizaciju.

SAML novcici se mogu koristiti za slanjeporuka u SOA okruzenjima, obicno u saradnjisa WS-Security ili drugim protokolima.

SAML 2.0 pruza podrsku za SSO. Pojedinitipovi SSO-a podrzani od strane SAML-a su:

• Identitetni SSO - Identitet korisnika je reg-istrovan u oba domena

• Atributni SSO - Kontrolu prava pristuparesursima izvrsavaju autorizacijski atributi

Anonimni SSO se postize prosledjivanjemSAML izjava o atributima, takodje postojimogucnost koriscenja pseudonima radi veceprivatnosti. SAML Web browser SSO profilodredjuje kako tvrdnje o autentifikaciji prego-varaju izmedju pruzaoca identiteta i pruzaocausluga [6].

3.3.4. XACML

XACML(eXtensible Access ControlMarkup Language) je ekspresivni i fleksi-bilni jezik zasnovan na XML-u. Koristi seza dostavljanje polisa o kontroli prava pris-tupa resurisma i ukljucuje zahtev/odgovor(request/response) protokol za slanje upita opravima pristupa. On opisuje zahteve kon-trole prava pristupa i moze se prosirivatidefinisanjem novih funkcija, tipova podatakai logikom.

XACML profil specifikuje pet glavnih gresakaza obradu odluke o pristupu:

1. Policy Enforcement Point (PEP)

2. Policy Administration Point (PAP)

3. Policy Decision Point (PDP)

4. Policy Information Point (PIP)

5. A context handler.

• PAP je repozitorijum politika i obezbedju-je politike za PDP

• PEP je interfejs celog okruzenja zaspoljasnji svet. Prima zahteve pristupai ocenjuje ih uz pomoc drugih ucesnika idozvoljava ili odobrava pristup reursu

• PDP je glavna tacka za donosenje odlu-ka o pravima pristupa. Prikuplja sveneophodne informacije od drugih ucesnikai donosi odluku

• PIP je tacka gde se potrebni atributi zaprocenu polise dobijaju od nekoliko ekste-rnih ili internih ucesnika

Slika 4. XACML ucesnici i tok podataka

Slika 4. ilustruje ucesnike i tok podataka.PAP kreira XACML polise za resurse i ciniih dostupnim PDP-u. Kada subjekat zatrazipristup resursu PEP salje zahtev o pristupuupravljacu konteksta(context handler), kojiprenosi zahtev PDP-u. PDP trazi pristupatributima subjekta, resursa i okruzenja da bimogao da donese odluku o pravima pristupa.Zahtev za atributima se salje PIP-u i on ihvraca. Kada PDP dobije informaciju vracaautorizacijsku odluku, kroz upravljac kontek-sta, PEP-u. PEP donosi odluke na osnovu

7

obaveza koje se dobijaju od strane servisaobaveza(obligation service).

Iako XACML pruza zahtev/odgovor (re-quest/response) protokol za mnoge od inter-akcija na slici 4., velika kolicina informacijamoze biti prosledjena i SAML novcicima imnoge razmene mogu koristiti SAML pro-tokol. XACML se prevashodno fokusira namehanizme koji omogucavaju pristizanje au-torizacijskih odluka.

XACML moze produziti autentifikacijumehanizmon dozvola u portalu veb uslu-ga i koristi prvenstveno njegovo prosirenjejezika. Politika servera koristi XACMLza izrazavanje i skladiscenje politika upreduzecu. Buducnost uspeha XACML pro-toka ostaje da se vidi.

3.4. Klasifikacioni kriterijum i klasi-fikaciono drvo

Za klasifikacione kriterijume kod ovog istra-zivanja su izabrani najcesci sigurnosni izazoviServisno Orjentisane Arhitekture kao sto suautentifikacija, autorizacija, poverljivost, in-tegritet i nemogucnost poricanja. Tabela nizesumira kriterijume koji su korisceni u procesuodlucivanja najbezbednijeg sigurnosnog stan-darda.

Au

ten

tifi

kaci

ja

Au

tori

zaci

ja

Pove

rlji

vost

Intg

rite

t

Nep

ore

civo

st

PKI + + + +

Kerberos + + +

WS-Security + + + +

XML Digitalni potpis + + +

SAML + +

XACML + +

Tabela 1: Klasifikacioni kriterijumi

Autorizacija

Da

Neporecivost

Da

Intgritet

Da

XML

Ne

Intgritet

Ne

SAML

Ne

Neporecivost

Da

Intgritet

Da

PKI

Ne

Intgritet

Da

Kerberos

XACML WS-SecuritySlika. 5 Klasifikaciono drvo

Klasifikaciono drvo rezimira osnovne kri-terijume koji se koriste u procesu donosenjaodluka za izbor odgovarajuceg bezbednosnogstandarda. Za kontrolu pristupa u ServisnoOrjentisanoj Arhitekturi brinu se SAML iXACML. Autorizacija je obicno pod kon-trolom pruzaoca usluga. Kerberos sprovodikljuceve sesije koji su bazirani na klijent- server komunikaciji koja je vremenskiogranicena i na taj nacin obezbedjuje in-tegritet. PKI pored integriteta obezbedjujei neporecivost jer se potpisivanjem privatnihentiteta podatak moze koristiti kao neporecivdokaz da podaci poticu od datog lica.

4. Trendovi i optimalnaresenja za buducnost

Trendovi se mogu opisati kao veomaspecificni delovi tehnologije ili kao prolazneideje to jest tacke gledista. Oba pogleda mogubiti veoma mocna pri oblikovanju buducnostiSOA-e. Najveca koris od SOA-e je eksibil-

8

nost. SOA omogucava brzu promenu infras-trukture preduzeca kao odgovor na promene uposlovnom okruzenju jer je vecina poslovnihprocesa vec dostupna u obliku veb servisa.

Najelegantnija i najsigurnija resenja suobicno i najednostavnija. Sto je veca ko-mpleksnost resenja veca je mogucnost uvo-djenja gresaka i slabosti. Da bi omogucilikompletnu sigurnost sistema neophodno je daprimenimo sve elemente bezbednosti (auten-tifikaciju, autorizaciju, poverljivost, integriteti nemogucnost poricanja).

Slika 6. Predlozeni sistem

Sistem koji je prelozen na slici 6. pre-dstavlja sveobuhvatan pristup potreban zaosiguranu komunikaciju izmedju servisa i ko-risnika. Neophodno je da se obezbedi be-sprekoran razgovor izmedju razlicitih admin-istrativnih domena.

Glavne komponente predlozenog sistema suprikazane ispod:

1. Service Requester (najcesce veb pre-trazivac) − Klijent koji zeli da koristiservis

2. Perimeter Service Router − prihvataporuke iz spoljnih aplikacija i rutira ihdo odgovarajucih veb servisa na privat-noj mrezi

3. Web server − odrzava jednostavne us-luge u okviru granica organizacije

4. Web Application Server − brine o inter-akcijama razlicitih veb servisa

5. Policy Server − sastoji se od Policy En-forcement Point i Policy Decision Pointpolitika i interaguje sa trecom stranomza verifikaciju i validaciju sertifikata

6. Trusted Third Party − verifikuje,potvrdjuje usluge i izdaje sertifikate

5. Zakljucak

U ovom istrazivackom radu zakljucio samda ni jedan bezbednosni standard sam po sebinije dovoljan. Sigurnost standarda i tehnikeServisno Orjentisane Arhitekture dolaze za-jedno sa nekim dodatnim temama:

♣ SOA forsira visoku interoperabilnost kojasmanjuje sigurnost

♣ SOA mora da se izbori sa heterogenim si-gurnosnim konceptima postojeceg sistema

♣ Distributivni proces se prenosi prekomnogo servisa tako da ”point-to-point”resenja nisu dobra za ”end-to-end” si-gurnost

♣ Multiklijent sposobnosti zahtevaju vre-mensku promenu sigurnosti

♣ Sigurnost utice na performanse servisa

Sledece tacke treba uzeti u obzir pri diza-jniranju bezbednosti za usluge orjentisanearhitekture:

1. Odrzavanje sigurnosti od pocetka

2. Pripremanje, pracenje i primenjivanjesigurnosnih polisa

3. Kreiranje svesti bezbednosti medjusvim akterima na svim nivoima

9

Bezbednost se moze poboljsati preuzima-njem odgovarajucih mera na nivou oper-ativnog sistema, nivou mreze, aplikacije inivou baze podataka. Uz prosirenje SOA-e ka racunarstvu u oblaku, sistemi postajupodlozniji bezbednosnim pretnjama. Novijiposlovni modeli koji nastaju zahtevaju ekspo-nencijalno unapredjenje tehnologije. Poredbezbednosnih aspekata koji se razmatrajuu ovom radu izazovi vezani za integracijurazlicitih politika moraju pazljivo da seresavaju.

References

[1] Introduction to digital certificates.URL http://www.verisign.com.

au/repository/tutorial/digital/

intro1.shtml#step1.

[2] Basic components of a publickey infrastructure. URL http:

//technet.microsoft.com/en-us/

library/cc962020.aspx.

[3] Wei Jie, Junaid Arshad, Richard Sinnott,Paul Townend, and Zhou Lei. A reviewof grid authentication and authorizationtechnologies and support for federated ac-cess control. ACM Computing Surveys(CSUR), 43(2):12, 2011.

[4] Mike P Papazoglou and Willem-Jan VanDen Heuvel. Service oriented architec-tures: approaches, technologies and re-search issues. The VLDB journal, 16(3):389–415, 2007.

[5] Poonkavithai KalamegamPoonkavithai Kalamegam and Za-yaraz Godandapani Zayaraz Godanda-pani. A survey on testing soa builtusing web services. International Jour-nal of Software Engineering and ItsApplications, 6(4):91–104, 2012.

[6] Michael Rosen, Boris Lublinsky, Kevin T.Smith, and Marc J. Balcer. Applied soa:Service-oriented architecture and designstrategies, 1 2010. URL http://amazon.

com/o/ASIN/B008O5K7S8/. 10