• Nem Talált Eredményt

Biztonsági implementáció a SOA rendszerekben

In document Szolgáltatás-Orientált Architektúra (Pldal 118-121)

Ebben a szakaszban néhány közös összetevőt mutatunk be, melyek a korábban vázolt technológiákon alapulnak.

Ezeket az összetevőket egy SOA referenciaimplementáció biztonsági szolgáltatásainál lehet jól alkalmazni. A szolgáltatásorientált architektúra implementálása során kulcsfontosságú üzleti átalakítás a (közös) biztonsági szolgáltatások felismerése és olyan üzleti folyamatok fejlesztése, amelyek kiaknázzák ezeket a szolgáltatásokat.

A kezdeti implementáció minden valószínűség szerint az infrastruktúra meglévő elemeiből épül majd fel, alapvető biztonsági szolgáltatásokkal kiegészítve egy vegyes környezetben.

5.1. Alapvető biztonsági szolgáltatások implementációja

8.7

A 8.1. ábrán látható alapvető biztonsági architektúra két fő biztonsági összetevőt tartalmaz: a kapcsolópontot (PoC – Point-of-Contact) és a bizalmi szolgáltatást, melyeket a következő szakaszokban részletesen kifejtünk. A 8.1. ábrán ezenfelül két különböző kapcsolópont elemet is megfigyelhetünk, ezek a szállítási rétegbeli PoC és a webszolgáltatás-PoC.

8.1. ábra - Alapvető biztonsági architektúra

Ebben a többféle protokollt és tartományt illusztráló vegyes példában a SOA kérések SOAP/HTTP protokollhoz vannak kötve. Ez a megközelítés lehetővé teszi, hogy a SOA architektúra újrahasznosítsa a SOA előtti architektúra részeit, beleértve a HTTP (szállítási réteg) összetevőit is. Az architektúra egy külső demilitarizált zónát (DMZ) is tartalmaz (ez két biztonsági tartomány közötti semleges zóna), amely egy hagyományos HTTP (SSL) biztonsági PoC bemenetet tartalmaz. Amikor a szoftver egy kölcsönösen hitelesített SSL kapcsolatot épít ki, a folyamat része a kérelem durva hitelesítése.

Az architektúra része egy belső DMZ, amellyel a PoC webszolgáltatása az üzenet ellenőrzését biztosítja. A webszolgáltatás-PoC a tényleges üzenethitelesítés részeként igénybe veheti a bizalmi szolgáltatást a megbízható hálózaton belülről. Ebben a példában azt figyelhetjük meg, hogy a PoC webszolgáltatásai hogyan alkalmazzák a RMI/IIOP protokollt a bizalmi szolgáltatással való kommunikációra. Emellett a webszolgáltatás a beérkező SOAP/HTTP kéréseket SOAP/JMS kéréssé alakítja át.

A bizalmi szolgáltatás olyan architekturális elem, amely megalapozza a partnerek közötti bizalmi kapcsolatot. A bizalom alapja a bejövő üzenet validálása, amely többek között magában foglalja az üzenetben állított azonosságok hitelesítését, illetve az azonosságok leképezését szerepkörökre a partnerekkel kötött üzleti megállapodásoknak megfelelően. Minden egyes összetevőről külön-külön szó lesz a következő szakaszokban.

5.2. A kapcsolópont szolgáltatás implementációja

Az egyik elsődleges feladat a szolgáltatásorientált architektúrák meghatározásakor annak pontos megértése, hogy mit nyújt a szolgáltatás, illetve az ennek megfelelő interfészek rögzítése. A PoC szolgáltatás feladatai:

• A kérelmek és a kérelmezők hitelesítése

• A kérelmező munkamenetének kialakítása és kezelése (egy adott kérelmezőhöz köthető, adott munkameneten belül kiadott kérelmek és tranzakciók kezelése)

• A kérelmek engedélyezése a munkameneten belül

• A munkamenet megfelelő befejezése (szándékos kilépésnek vagy inaktív időtúllépésnek köszönhetően) Mivel a PoC szolgáltatás dolgozza fel a bejövő kéréseket, ő felelős a szállítási réteg biztonságáért és a jogosulatlan kérések szűréséért. Vegyes környezetben a szolgáltatás a biztonságos szállítási réteg technikájára támaszkodik:

• SSL munkamenet befejezése

• A kérelem hitelesítése a biztonságos szállítási rétegre alapozva (például SSL tanúsítványok alapján, melyeket a partnerek kölcsönös hitelesítésére használnak)

SOAP előtti környezetekben a HTTP-alapú kapcsolópont általában a következőkért felelős:

• A felhasználó vagy a kérelmező hitelesítése a felhasználó által bemutatott hitelesítő adatokon alapján, legyenek azok közvetlenül felmutatható adatok, mint a felhasználónév és jelszó, vagy harmadik fél által kiadott igazolások, például SAML állítás.

• A kérelem engedélyezése a kért URL és a felhasználó hitelesített azonossága alapján

Sok korai felhasználó választott HTTP-alapú kapcsolópontot a külső DMZ-ben, ami csak az SSL tanúsítványban igazolt azonosság alapján történő durva szintű hitelesítést jelent. Így egy külső DMZ PoC SSL munkameneteket biztosít a különböző üzleti partnerekkel, és képes blokkolni az illetéktelen egyéneket (akik nem üzleti partnerek, de SSL-tanúsítványuk sincs) a belső DMZ-be történő bejutástól.

A rendszer bővítése egy belső DMZ-vel és a SOAP üzenetek megvizsgálására képes PoC szolgáltatással lehetővé teszi, hogy a rendszer továbbra is használhassa a SOA előtti környezetet. A PoC szolgáltatás specifikus funkcióikat lát el, mint például a tényleges kérelmező hitelesítése a webszolgáltatás-kérelemben foglalt információkra alapozva. Ez a belső DMZ PoC szolgáltatás útvonalválasztást is kínál, képes átirányítani a webszolgáltatás-kérelmeket a megfelelő háttérforráshoz. A továbbfejlesztett PoC-k akár protokollátalakításokat is végeznek, így egy belülről JMS-alapú webszolgáltatást például HTTP kötéssel közvetítenek a külső világ felé.

Általánosságban elmondható, hogy az egy vagy több kapcsolópontra kiterjedő PoC szolgáltatás funkcionalitása tartalmazza a hitelesítést, a munkamenet-kezelést, valamint a hatálya alá tartozó biztonságos szállítási és üzenetréteg szolgáltatást.

5.3. Üzenetréteg-beli biztonsági szolgáltatások implementációja

Az üzenetréteg biztonsági szolgáltatásait általában az infrastrukturális összetevőkben implementálják, amelyek az üzenet végpontban történő megérkezéséről és útvonalválasztásáról gondoskodnak. Ezek a szolgáltatások lehetővé teszik, hogy a rendszer sokkal nagyobb mértékben védhesse az üzenetet, mint a biztonságos szállítási réteg, ahogyan azt a 8.2.3. szakaszban is említettük.

A finomszemcsés biztonságos üzenetréteg implementációjának magas költségei miatt a biztonságos üzenetrétegben általában durvaszemcsés megoldásokat alkalmaznak (titkosítják az egész üzenetet), és az üzenet csak azon szempontjai képezik finomszemcsés technikának tárgyát, amelyek teljes védelmet igényelnek.

5.4. Bizalmi szolgáltatások implementációja

A PoC szolgáltatások funkcionalitása az üzenetek és a kérelmezők hitelesítésére is kiterjed. A PoC szolgáltatások bizalmi szolgáltatásokat vesznek igénybe a webszolgáltatások biztonsági tokeneinek kezeléséhez, ahogyan azt a 8.3.5. szakaszban ismertettük. Az egyszerű kérelmezőhitelesítés annyit tesz, hogy a biztonsági tokenben használt azonosság jelenti a hitelesített azonosságot. Néha ennél bonyolultabb funkciókat is biztosítani kell, mint például a tokenek cseréjét (közvetítői szerepben), vagy a beérkező azonosságok részletes leképezését (pl. egy azonosság leképezése az alkalmazás egy szerepkörére). A bizalmi szolgáltatások kezelik és védik a biztonsági tokeneket.

5.5. A szövetség implementációja

Egy kiegészítő összetevő, amit a 8.1. ábra nem mutat, a szövetség protokoll szolgáltatáskomponens, mivel eddig a SOA-t egy B2B típusú környezeten belül értelmeztük. Sok esetben azonban a közvetlen böngészőalapú interakciókat a SOA környezet részének tekintik. Ez azt jelenti, hogy a felhasználókat hitelesíteni kell a böngészőben a különböző üzleti partnereken keresztül. Ezt a folyamatot nevezzük tartományok közti egyszeri bejelentkezésnek. A végső cél az, hogy csökkentsük a felhasználói hitelesítések számát az ugyanazon üzleti kapcsolathálóhoz és környezethez tartozó vállalatoknál. Ahhoz, hogy ezt kezelni tudjuk, egy kiegészítő szolgáltatás szükséges, amely a különböző egyéni bejelentkezések protokollját kezeli. Ezt nevezzük protokollszolgáltatásnak, amint azt a 8.2. ábra is mutatja.

8.2. ábra - Alapvető biztonsági architektúra protokollszolgáltatásokkal kiegészítve

A protokollszolgáltatás általában egy hagyományos háttéralkalmazás, amely a HTTP-n keresztül hozzáférhető erőforrásokhoz hasonló formában érhető el. A szállítási rétegbeli PoC a kérelmet a protokollszolgáltatáshoz irányítja, ami ezáltal gondoskodik a partnerek közti egyszeri bejelentkezésről. Érdemes megjegyezni, hogy ez a HTTP-alapú egyéni bejelentkezés mindig kapcsolatba lép a felhasználók böngészőivel. Így továbbra is alkalmazhatók a már meglévő szállítási rétegbeli PoC technikák a böngészővel fenntartott munkamenet kezelésére. Miután megvalósítottuk a HTTP-alapú egyszeri bejelentkezést, a felhasználók tetszőleges háttéralkalmazást vehetnek igénybe, amihez engedély kapnak.

6. A biztonságra vonatkozó nem-funkcionális

In document Szolgáltatás-Orientált Architektúra (Pldal 118-121)