(dokončení včerejšího článku)
Skrytí interních zdrojů
Skrytí interních zdrojů a implementačních detailů je jednou ze standardních metod ochrany systémů. Příkladem maskování interních zdrojů je politika propagace nebo potlačení http hlaviček, které by mohly vypovídat o implementaci poskytovatele služby.
Vynucení pravidel pro SLM
Vynucování pravidel pro Service Level Management (SLM) by mohlo být na první pohled spojeno s řízením přístupu ke službě, protože klientovi, který nějakým způsobem překročí nastavené a odsouhlasené politiky použití služby, je regulován nebo dokonce zamezen přístup k této službě.
Zmíněné vynucení pravidel má však nepřímý dopad na bezpečnost, protože ovlivňuje zatížení a stabilitu systémů (třeba aby nedošlo k přetížení poskytovatelů služeb). Důsledné aplikování však má značný vliv na efektivní využití IT zdrojů společnosti. Příkladem může být systém, kde bylo realizováno asynchronní volání pomocí návrhového vzoru využívajícího polling. Klienti (v tomto smyslu informační systémy) však byli nedisciplinovaní a zasílali požadavky výrazně častěji (snaha uspokojit uživatele co nejdříve). Agregované množství požadavků postupem času přerostlo rozumnou mez a celý systém se stal nespolehlivým. Jako rychlé řešení byl implementován prostředník, který zablokoval nadměrný provoz ještě před tím, než se o něm cílový systém dozvěděl. Navíc se díky monitorování podařilo postupným vyjednáváním s administrátory klientských systémů daná omezení respektovat.
Monitorování transakcí a inspekce
Monitoring transakcí představuje důležitou součást řešení SOA. Z bezpečnostního pohledu může být anomálií např. atypicky velká zpráva a dlouhý čas odezvy, které společně mohou naznačovat únik dat třeba v důsledku SQL Injection.
Monitoring transakcí není zcela jednoduchým úkolem a je vhodné použít řešení optimalizované pro tento účel. Tato řešení také obsahují nástroje, které pomáhají v odhalování podezřelých stavů a v jejich analýze. Při návrhu a realizaci dalších řešení (např. v průběhu dopadových analýz) může mít nedostatek monitorovacích informací kritický dopad na výsledek celého snažení, případně vede na předimenzování systému a jeho komponent.
Vývoj standardů
V současné době není vývoj bezpečnostních standardů příliš bouřlivý. Postupně dochází k vylepšením standardů WS-SecureConversation 1.4 společně s WS-Trust 1.4 a standardem WS-SecurityPolicy 1.3. Základní principy volby mezi využitím WS-Security a WS-SecureConversation jsou stále stejné. Pokud mají služby konverzační charakter, lze k zajištění zpráv použít WS-SecureConversation, kdy je zpráva šifrována i digitálně podepsána proměnlivými klíči v každé relaci. Podstatným kritériem je také to, zda je či není vyžadováno prokazatelné spojení identity s přenášenou zprávou v podobě digitálního podpisu na základě klientského certifikátu (může být požadováno podle různých regulačních pravidel).
Zatím se nijak neprojevilo rozšiřování OpenID ve spojení s klasickými (SOAP) webovými službami (například by bylo možno očekávat WS-Security Token pro OpenID identity identifikátor). OpenID je výrazně více spojen s webovými aplikacemi a webovými službami typu REST. U klasických webových služeb SOAP převládá v souvislosti s propagací identity a federovanými identitami použití standardu SAML.
Využití standardu SAML
Pokud je k propagaci identity uvnitř nebo vně organizace (častější případ) použit SAML, je preferovaným řešením vkládání celého SAML Assetion, které obsahuje všechny důležité informace o identitě.
SAML Assertion obsahuje zejména základní údaje o identitě a způsobu ověření (Authentication statement) a dále tzv. atributy, které blíže specifikují informace o identitě tak, jak je vnímána na straně klienta. Často se jedná o doplňkové personální informace jako jméno, e-mail, telefon nebo informace popisující obchodní kontext (např. že identita působí na straně klienta jako prodejce).
Velmi důležitou součástí je digitální podpis, kterým klient prokazuje, že danou osobu ověřil a je tedy pro poskytovatele služby důvěryhodná. Informace o obchodním kontextu identity jsou často použity na straně poskytovatele služby k autorizaci, zda má být požadovaná operace vykonána a zda má klient přístup k požadovaným datům.
Příklad práce se SAML Assertion z pohledu klienta je naznačen na Chyba: zdroj odkazu nenalezen. Interní uživatel zasílá požadavek s vnitřní reprezentací klienta (třeba jméno a heslo v WS-Security UserName tokenu).
Před tím, než je požadavek odeslán na poskytovatele služby, provede klient ověření identity (autentifikaci) založenou na interní reprezentaci identity (např. ověření poskytnutého jména a hesla). Po ověření identity následuje zpracování volitelným, avšak doporučeným krokem interní autorizace.
V autorizaci se prověřuje, zda interní uživatel je oprávněn volat službu u poskytovatele služeb (důležité zejména u placených služeb). Dopadne-li autorizace dobře, je vytvořena SAML Assertion naplněná informacemi o klientovi a předána zpět.
Pro autentifikaci, autorizaci a přemapování identity se často využívají systémy spadající do kategorie Federated Identity Manager a ke komunikaci se využívá standard WS-Trust. Díky využití standardu WS-Trust je zajištěna interoperabilita mezi různými produkty Federated Identity Manager z pohledu klienta služby, který provádí volání poskytovatele služby. Klient pošle výslednou zprávu včetně SAML Assertion na poskytovatele služby.
Základním přínosem využití řešení postaveného na SAML je, že poskytovatel služby nespravuje identity koncových uživatelů svých klientů. Na druhou stranu je vyžadována důvěra mezi poskytovatelem služby a klientem služby. Poskytovatel služby musí důvěřovat, že na straně klienta není kompromitován systém pro správu identit a jejich ověřování.
Závěr
V celosvětovém měřítku roste počet integrovaných řešení, která se zaměřují na podporu nových obchodních modelů a přesahují rámec jedné organizace (jak běžné společnosti, tak i ve státní správě). Na druhou stranu roste pomyslná cena informací jako konkurenční výhody. Je proto nutné již při návrhu řešení dbát na přiměřenou míru zabezpečení.
Vyplatí se v maximální možné míře využívat standardy, protože jsou již do značné míry podporovány v produktech pro realizaci řešení SOA a přináší tak flexibilitu, která je jedním z příslibů této kategorie řešení. Rozhodně je vhodné zvolit přístup „Security by design“ než přístup „Security by obscurity“ a při volbě prostředků přihlížet k hodnotě chráněných informací v širším kontextu organizace.
Tento článek vyšel v tištěném SecurityWorldu 1/2009.
PŘEDPLATNÉ
ČLÁNKY DO MAILU