Zabezpečujeme webové služby a SOA (1)

Příkladem takových řešení je elektronická podpora end-to-end obchodních procesů (Business Process Management), které skrz různé kanály integrují lidi a systémy ve společnosti i mimo ni. Technologicky je se SOA architekturou spojena technologie WebServices, neboli webových služeb. Je zcela zřejmé, že tyto jevy přináší celou řadu bezpečnostních aspektů, které je nutno řešit.

Ukazuje se, že nejúčinnější ochranou před riziky spojenými s WebServices a XML daty je využití tzv. prostředníka, který centralizovaně prosazuje nastavenou bezpečnostní politiku nad probíhající komunikaci (nemusí se vždy jednat jen o WebServices, ale i jiné formáty dat používané např. v B2B řešeních).

Ještě dnes se objevují řešení, jejichž bezpečnost je vyřešena samostatně na každém poskytovateli služby . Tento přístup se však nedá označit za „best practice“. Poskytovatelé služeb se musí jednak vyrovnat s řadou bezpečnostních aspektů (třeba v případě útoku typu Public Key DoS se musí umět každý poskytovatel služby vypořádat se zátěží generovanou matematickou podstatou asymetrické kryptografie), dále takto decentralizovaný přístup s distribuovanými bezpečnostními politikami vede také k nekonzistencím a přináší zvýšení administrátorských a vývojových nákladů (řešení stejného problému na více systémech nebo platformách).

Přístup k řešení bezpečnostních aspektů SOA pomocí prostředníka vyplývá ze základního požadavku na bezpečnostní řešení – eliminovat veškerá rizika co nejdříve. Pro řešení zabezpečení poskytovatelů služeb existuje sada doporučení:

• Validace zpráv

• Řízení přístupu ke službě

• Použití digitálních podpisů

• Použití šifrování na úrovni zprávy

• Skrytí (maskování) interních zdrojů a implementačních detailů

• Vynucení pravidel pro Service Level Management

• Monitorování všech transakcí a inspekce podezřelých stavů

Validace zpráv

Do oblasti validace zpráv spadá zejména kontrola základních charakteristik, tj. zda je zpráva v předpokládaném formátu (třeba XML), zda se jedná o služby používající protokol SOAP a podobně. Například u formátu XML je vhodné prověřit validitu zpráv, resp. požadavků a odpovědí proti XML schématu, což výrazně zvyšuje odolnost proti útokům typu SQL Injection nebo XPath Injection a jeho variant.

Ovšem XML schéma, které řeší bezpečnostní aspekty, by mělo být konkrétní. Je zcela pochopitelné, že použití parametru xsd jako „any“ nebo „anyType“ snižuje bezpečnostní hodnotu schématu a umožňuje vkládání potenciálně nebezpečných fragmentů.

Dalším vhodným typem validace zpráv je antivirová kontrola. Zprávy často obsahují data v binární podobě, a to buď přímo v těle zprávy, nebo jsou využity jiné metody pro přenos příloh (SOAP with Attachments nebo lepší MTOM). Tento druh validace je někdy společnostmi implementujícími SOA postavenou na WebServices zcela přehlédnut.

E-mailový server zabezpečený antivirovými systémy je již standardem, přitom však může existovat nezabezpečený kanál, který umožní uložit zavirovaný dokument například do Document Management Systemu v rámci B2B komunikace. Pak ke vzniku reálného bezpečnostního rizika stačí drobný přestupek na pracovní stanici některého z uživatelů jako třeba vypnutý nebo neaktuální antivirový systém.

Do oblasti validace zpráv také patří prohledávání obsahu na základě různých vzorů (pattern scan), které může dále zvyšovat odolnost proti útokům SQL Injection a XPath Injection.

Řízení přístupu ke službě

Pod řízením přístupu ke službě se má na mysli zejména autentifikace a autorizace. Jejich potřeba ve společnosti je zřejmá. Prvním krokem procesu autentifikace je extrakce identity ze zprávy nebo komunikačních metadat. S tím, jak roste interoperabilita řešení u klasických služeb SOAP a nutnost širší integrace společností, roste i počet řešení, které využívají standardy WS-Security – tokeny, které obsahují informaci o identitě (UserName token, BinarySecurity Token, SAML Token).

Stále se vyskytuje nevhodné použití BinarySecurity Tokenu s klientským certifikátem jako samostatného zdroje o identitě klienta služby. Zmíněný token sám o sobě neříká, zda zprávu skutečně zaslal klient definovaný identitou v předloženém certifikátu (ten obsahuje „veřejné“ informace, které z principu nebývají skryté).

BinarySecurity Token je možno např. „odposlechnout“ a pak přidat ke škodlivé zprávě a jako věrohodný nositel informace o identitě klienta funguje pouze ve spojení s digitálním podpisem zprávy. V případě použití digitálního podpisu roste zajištění zprávy významnou měrou, protože nese nejen informaci o identitě klienta pro účely autentifikace, ale zároveň je chráněna její integrita.

Kromě autentifikace a autorizace patří do oblasti řízení přístupu ke službě také audit. Běžně zažitým vzorem v oblasti Enterprise Service Bus (ESB) je audit příchozích a odchozích zpráv a skoro všechny produkty ESB tuto aktivitu do určité míry podporují. Na druhou stranu tak ovšem vzniká nový datový sklad, kde jsou uložena data zkorelovaná v kontextu, jak společnost funguje.

Takový auditní log může být zdrojem celé řady citlivých informací, proto se musí dobře zabezpečit (např. digitální podpisování pro zajištění integrity, šifrování pro ochranu citlivých údajů) a zároveň je nutné stanovit, kteří pracovníci a za jakých podmínek k logu mají přístup.

Použití digitálních podpisů

Použití digitálních podpisů je velmi důležité jak z pohledu prokázání původu zprávy, tak z pohledu ochrany její integrity. Zpráva je tímto způsobem chráněna před případnými útoky typu „man in the middle“, kdy dochází k modifikaci obsahu zprávy.

U webových služeb může klient k digitálnímu podpisu zprávy použít svůj privátní klíč (který lze chránit například v HSM modulu) a poskytovateli služby předkládá svůj certifikát obsahující informace o identitě a dále veřejný klíč. Tento provider by měl nejen ověřit validitu digitálního podpisu zprávy s použitím veřejného klíče, ale také prověřit platnost klientského certifikátu u certifikační autority (vhodné je využití také CRL nebo OSCP, pokud je certifikační autorita poskytuje).

Je-li ověřen digitální podpis i certifikát prezentovaným klientem na straně poskytovatele služeb, doporučuje se provést na základě identity extrahované z poskytnutého certifikátu také autorizaci, zda má mít uživatel přístup ke službě a jejím datům. Tento přístup odpovídá použití základního standardu WS-Security. Pokud je potřeba zprávu chránit pouze proti modifikacím na přenosové trase, je možné použít také standard WS-SecureConversation, kdy je každá zpráva také digitálně podepsána.

Pokud se mluví o digitálním podpisu zprávy, často tím celá řada vývojářů má na mysli podpis pouze části SOAP Body ve zprávě. Tak tomu však není.  Často se používá WS-Addressing ke směrování zpráv, zejména při implementaci asynchronní komunikace. Aby byly zprávy chráněny, měly by být podepsány také hlavičky SOAP obsahující informace, které identifikují zprávu a její směrování. Tento digitální podpis chrání hlavičky před jejich přepisem prostředníkem a odpovídající backend systém tak bude zasílat odpověď na systém, který předpokládal klient a nikoliv útočník.

K validaci digitálních podpisů patří také ověřování standardních časových známek digitálního podpisu (timestamp), které znesnadňují tzv. Reply attack. Ještě v dnešní době se vyskytují systémy, které spolu komunikují a přitom nemají koordinovaný čas a u kterých je zmíněná kontrola časových známek a životnosti zprávy vypnuta.

Šifrování na úrovni zprávy

Šifrování je základní cestou, jak ochránit citlivá data ve zprávách. Často se v praxi používají kódované transportní protokoly jako HTTPS, avšak takové řešení přináší point-to-point zabezpečení - na rozdíl od šifrování zprávy, které poskytuje širší end-to-end zabezpečení a navíc může pomoci v řešení problematiky ukládání dat v auditním logu. Pokud je třeba odpověď poskytovatele služby zašifrována pomocí veřejného klíče klienta služby, je nutné mít k jejímu dešifrování privátní klíč klienta služby. Již sám tento fakt komplikuje případné zneužití informací z auditních logů, kdy je nutno získat jak privátní klíč klienta, tak přístup k logu.

Další oblastí, kde se šifrování na úrovni zpráv uplatňuje, je použití standardu WS-Addressing ve spojení s možnostmi, které nabízí WS-ReliableMessaging. Tento mechanismus vytlačuje dříve běžný vzor polling, kde se klient služby v pravidelných intervalech ptá, zda je jeho požadavek již zpracován a s jakým výsledkem. Výše zmíněné standardy zajišťují asynchronní doručení na klienta bez jakékoli aktivity z jeho strany.

Ovšem je nutné počítat s tím, že po dobu, než se podaří doručit odpověď z poskytovatele služby na klienta, bude zpráva (třeba z důvodu výpadku síťové komunikace mezi poskytovatelem a klientem) uložena na disk (například v relační databázi či v souboru).

Po tuto dobu jsou data dostupná každému, kdo má přístup ke zmíněné DB a případně se mohou taková data vyskytnout i v zálohách systému (mimo jiné zálohování transakčního logu DB). K podobnému jevu může dojít také při využití různých messaging systémů (JMS, MQ…).

Tento fakt si uvědomují i autoři PCI Data Security Standardu (PCI DSS) v oblasti práce s daty, která jsou spojena s transakcemi z platebních karet. Mezi základní požadavky specifikace patří nejen bezpečné přenosy dat/zpráv po síti (zejména veřejné síti), ale je kladen důraz i na šifrování dat, která jsou např. ve frontách.

Pokud jsou chráněny zprávy při přenosu a ve frontách, které řeší doručení zpráv, v auditním logu existuje ještě jedno místo, které je potřeba dobře chránit. Jedná se o úložiště stavu různých Business Process Management řešení, které jsou v dnešní době s pojmem SOA nerozlučně spojena. Je nutno volit vhodné návrhové vzory pro ukládání dat (např. se šifrováním údajů), řídit jaký uživatel má přístup ke konzoli pro monitoring a řízení elektronických obchodních procesů, audit operací a podobně.

(dokončení článku)

Tento článek vyšel v tištěném SecurityWorldu 1/2009.