Aspekty bezpečnosti v SOA

SOA - architektura zaměřená na služby - znamená ve svém důsledku integraci nejrůznějších systémů. Pro komunikaci s okolím jsou tak nejednou nově otevřeny systémy, které dosud pracovaly zcela odděleně od ostatních. Tak je dnes klidně možné aplikaci realizovanou v Cobolu na mainframe vystavit jako webovou službu použitelnou kdekoliv v internetu.


Je však systém, kde bezpečnost nebyla řešena na prvním místě, na takové otevření připraven? Odpověď bude pravděpodobně záporná. Odpovědnost za bezpečnost celého řešení tak do značné míry musí převzít samotná SOA infrastruktura resp. její ESB řešení. Implementace zabezpečení nebude jednoduchým úkolem a může mít nezanedbatelné nároky na výkon systémů.

I ve světě webových služeb, bez ohledu na to, zda je použit XML protokol SOAP nebo architektura REST, je nutno vyřešit celou řadu otázek:

• oprávnění klienta využít službu (authetizace a autorizace)
• validita požadavku, aby zpracování požadavku na cílovém systému nebylo jen plýtvání časem (např. pokud klient zasílá XML, je nutné prověřit, zda se jedná o platné XML příp. platný SOAP požadavek, zda jsou vlastní XML data platná dle XML schématu...
• vyhodnocení, zda zaslaná data nepředstavují bezpečnostní hrozbu pro cílový systém (v případě XML se jedná XML threats, SQL injection, omezení velikosti zpráv ap.)
• nezpochybnitelný audit požadavků a odpovědí služby
• digitální podpisy a validace digitálních podpisů zpráv
• šifrování a dešifrování zpráv

Jedná o generické (obecné) - stále se opakující úkony, které je však nutno efektivně řešit pro každou službu. Jak tyto úkoly realizovat s minimem úsilí? IBM využívá tzv. SOA appliance podobně, jako dříve společnosti vyrábějící síťové prvky odstanily generické úkony ze serverů a přenesly je na specializovaná zařízení (switche, routery, firewally, VPN). V nabídce jsou specializovaná HW zařízení IBM WebSphere DataPower XS40 pro zabezpečení webových služeb. Na obrázku je naznačeno typické využití SOA appliance:

SOA appliance je využita jako filtr požadavků - správněji jako bod vynucení bezpečnostní politiky (security policy enforcement point). Celá bezpečnostní politika je namodelována a nakofigurována ryche a jednoduše s minimem znalostí metodou drag&drop a pomocí wizardů. Pro rozhodnutí, zda je uživatel oprávněn provést operaci se standardně využívá systémů pro řízení přístupu (Access policy decision point). IBM jako jeden z klíčových dodavatelů systémů pro SOA infrastrukturu nabízí ve svém portfóliu produkt vhodný pro řízení přístupů i v oblasti webových služeb. Jedná se IBM Tivoli Access Manager. Na back-end systém, což může být buď přímo poskytovatel služby nebo interní sběrnice podnikových služeb (ESB), tak přichází jen validní a autorizované požadavky ke zpracování.

Jak bylo řečeno v úvodu, SOA vede k integraci. V dnešním globálním světě se však nejedná jen o integraci interních systémů společnosti, ale často o propojení celých řetězců procesů různých společností. Pak velmi důležitou vlastností služeb je, že mohou správně pracovat pouze v kontextu volajícího - je nutno provádět tzv. propagaci identity. Příklad je naznačen na obrázku:

Na uvedeném příkladu klient služby zasílá objednávku do společnosti A. Ve společnosti A je klient zaveden např. v CRM systému a má tak zřízena oprávnění pro přístup k objednávkové službě. Vyřízení objednávky však pro společnost A může znamenat nutnost oslovit dva partnery – společnosti B a C. Budou mít oba partneři ve svém systému identit zavedeného klienta společnosti A? Pravděpodobně ne. Řešení nabízí sdílení identity - tzv. federace identit. Ve světě webových služeb se pak může jednat o využití standardu WS-Security ve spojení s XML frameworkem SAML pro propagaci identit.

Co však je zásadní otázkou v oblasti federace identit? Důvěra! Společnost B i C musí věřit společnosti A, která o svém klientovi prohlásí, že je to opravdu on a že má tyto konkrétní atributy (např. spadá do kategorie zákazníků Gold).

Další otázkou je, jak zajistit důvěru společnosti A. Odpovědí je bezpečné a kvalitní řešení pro správu identit a řízení přístupů. Zde vstupují do hry řešení pro SOA infrastrukturu jako je SOA appliance XS40 a IBM Tivoli Federated Identity Manager. Na obrázku je naznačeno využití zařízení IBM WebSphere DataPower ve společnosti A, která je odpovědná za prověření skutečné identity klienta. Zřetězené společnosti B a C již využívají výsledku prvotního ověření. V zásadě se jedná o téma velmi blízké SSO (Single-Sign On):

Kromě standardního ověření přidá SOA appliance také informaci o klientovi do vlastní zprávy v podobě tzv. SAML assertion (prohlášení o identitě). Tato SAML asserion je dále použita při propagaci volání směrem k parterské společnosti B tak, jak je naznačeno na obrázku:

V prvním kroku je provedena validace SAML assertion – zde je nutná důvěra vzhledem ke společnosti A. V dalším kroku je provedena autorizace např. na základě atributů nastavených do SAML assertion (v našem případě jde o zákazníka úrovně Gold). Pokud je zákazník úrovně Gold oprávněn provést nákup ve společnosti B, může IBM Tivoli Federated Identity Manager generovat nový token, popisující identitu, který SOA appliance přidá do požadavku tak, aby identita byla správně rozpoznána v interních systémech společnosti B.

Jiří Melichna