Se složitostí systému roste riziko selhání

Se složitostí systému rostou požadavky na bezpečnost, zvyšuje se počet míst, kde může dojít k selhání, snižuje se celková dostupnost, a rostou celkové náklady na vlastnictví.

V praxi pak dochází k tomu, že příslušná bezpečnostní opatření nejsou dodržována, organizace se potýká mnohem častěji s výpadky systému, roste počet incidentů, prodlužuje se doba jejich řešení a vše v konečném důsledku může vést i k pomalejšímu zavádění inovací. Anebo je to všechno jinak?

Při návrhu zabezpečení webových aplikací ze strany bezpečnostního architekta nebo při provádění auditu ze strany auditora stiženého lehkou paranoiu se vám může snadno stát, že se dozvíte, že váš stávající systém je natolik děravý, že pokud ho nepředěláte podle předloženého návrhu nebo neimplementujete příslušná doporučení, tak do několika měsíců zkrachujete na následek APT útoku, na kterém se budou podílet i vaši zaměstnanci. Netřeba snad dodávat, že kdybyste provedli základní analýzu rizik, zjistili byste, že se tohoto útoku nejspíš nemusíte obávat, protože toto riziko je velice nízké.

Bezpečnostní architekt nebo auditor vám zcela jistě navrhne, aby za účelem zajištění vysoké dostupnosti byly jednotlivé komponenty i celé řešení zdvojeno a doporučí vám umístění každé vrstvy na samostatný  server a oddělení těchto serverů firewally s jasně definovanými pravidly komunikace, kdy spolu budou smět na daném portu komunikovat jen dva sousedící servery, které se budou oboustranně autentizovat, přenos dat mezi nimi bude šifrován, datové zprávy budou podepisovány a validovány na vstupu i na výstupu a jednotlivé moduly aplikace budou běžet pod účty s omezeným oprávněním.

Přístup k těmto serverům pak bude umožněn pouze vybraným administrátorům až poté, co se dvoufaktorově autentizují, a samozřejmě jejich veškerá činnost v systému bude auditována a monitorována, přičemž logy se budou ukládat do geograficky vzdálené lokality, aby nemohly být modifikovány. K tomu budou zavedeny i všechny odpovídající procesy podle ITIL, minimálně na stupni 3 CMM a též všechna opatření uvedená v katalogu ISO 27002. Koneckonců jsou to přeci celosvětově uznávané best practice, tak proč je nedodržovat, že?

Možná souhlasně pokyvujete hlavou a říkáte si, ano takhle by se měly bezpečné systémy stavět a spravovat. Ovšem dejte si pozor, aby výsledkem nebyl jen papírově superbezpečný systém, nad kterým sice zcela jistě zaplesá srdce nejednoho auditora velké čtyřky, ale vy jste se nepotýkali s obrovskými problémy, neboť takový systém bude příliš složitý a tudíž velice náročný na správu a další rozvoj a zavedená bezpečnostní opatření budou po čase velkou brzdou v rychlejším zavádění inovací.

Vícevrstvá architektura nám na jednu stranu umožňuje vertikální i horizontální škálování a možnost provést změnu na jakékoliv vrstvě, ale na straně druhé je mnohem náročnější na správu a zabezpečení. V takto složitém systému již nestačí jen ošetřit všechny chybové stavy, ke kterým může dojít v samotné aplikaci, ale budete muset ošetřit i nedostupnost nebo nefunkčnost jednotlivých komponent běžících na různých serverech a pod různými účty, a pro všechny vytvořit failover scénáře.

Roztříštěné know-how

Vzhledem k tomu, že správu takto komplexního systému již nemůže provádět jedna osoba, bude nutné odpovědnost za správu jednotlivých komponent a komunikaci mezi nimi svěřit různým osobám, což povede k roztříštění know-how a vy nebudete mít nikoho, kdo by rozuměl danému systému jako celku. V konečném důsledku toto oddělení pravomocí povede k tomu, že byť nikdo nebude mít plnou kontrolu nad celým systémem a nebude moci tak snadno spáchat podvod, tak stejně tak nikdo nebude schopen snadno obnovit funkčnost systému v případě jeho napadení nebo havárie.

Vyšší TCO

Připravte se na to, že se vzrůstající složitostí systému nejspíš porostou i celkové náklady na vlastnictví. Správa systému běžícího na několika různých platformách, vzrůstající složitost síťové infrastruktury nutná k zajištění vysoké dostupnosti, bezpečnostní opatření, implementovaná na jednotlivých vrstvách, monitoring jednotlivých serverů a komponent od různých dodavatelů za účelem včasné detekce selhání, a dále pak nucený upgrade a aktualizace všech komponent z důvodu nově objevených zranitelností a s tím spojené integrační a další testy budou zcela jistě klást značné nároky nejenom na lidské zdroje.

Horší dostupnost

I když systém složíte z komponent, u kterých bude garantovaná dostupnost vyjádřena magickými šesti devítkami, tak celková dostupnost systému bude dána součinem dostupnosti jednotlivých komponent. To znamená, že čím složitější systém budete provozovat, tím většímu riziku selhání jedné z mnoha komponent budete vystaveni, neboť se vzrůstající složitostí jednoduše poroste počet míst, kde může dojít k selhání.

Závěr: Pokud navrhujete nějaký pro organizaci kritický systém, usilujte raději o co nejjednodušší systém, kde se dají implementovat účinná bezpečnostní opatření, která budou vaši zaměstnanci dodržovat i v delším časovém horizontu. Pokud vytvoříte monstrum, otestujte si svůj DRP a doufejte, že podle něj nebudete muset nikdy postupovat.

Štítky: n-tier

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.