Manažer bezpečnosti: Za hlasem virtualizace...

Na kongresu získal náš manažer poznatky o bezpečnostních dopadech virtualizace a nasazení konfigurační databáze (CMDB).

Před pár týdny mě šéf požádal, abych zvážil svou účast na jednom kongresu IT. Už ze zvyku se každým rokem zúčastňuji konferencí o systémové správě, networkingu i o bezpečnosti. Šéf mi ale nyní navrhoval, abych vypadnul z kanceláře na týden, a to do Las Vegas. To se nedalo odmítnout. Hotel i letenku jsem měl rezervované během jediné hodiny.

Konference bývají velkolepé a v rámci této akce bylo na pořadu hodně zajímavých přednášek na téma bezpečnost IT, zřejmě víc než k jakémukoliv jinému tématu. Připadáte si jako dítě v cukrárně, chcete být u všeho najednou a nevíte, co dřív. Měl jsem v plánu soustředit se na určitá témata a k těm se dozvědět maximum informací. Jako zásadní témata jsem si nakonec zvolil virtualizaci a řízení konfigurací.

Virtuální nadšení
Virtualizace není žádnou novinkou, pokud pracujete ve velké organizaci s mainframovými systémy, ale v naší společnosti je to žhavým tématem právě teď. Virtualizujeme serverové prostředí téměř pro každou novou aplikaci, kterou zavádíme, dost radikálním způsobem a navíc spoustu aktuálně užívaných aplikací do takových prostředí zároveň převádíme.

Je jasné, že rovněž virtualizace má určité bezpečnostní dopady. Například v typických architekturách pro aplikace založené na webu jsou web, samotná aplikace i databázový server instalovány na odděleném hardwaru a každý z nich má svůj operační systém zabezpečený podle individuálních pravidel a také odpovídajícím způsobem patchovaný. Pro segmentaci zdrojů zde existují také virtuální sítě a firewally, jež jsou nakonfigurovány tak, aby bylo zajištěno, že vztahy mezi webovým serverem i aplikačním a databázovým serverem jsou nastaveny podle opravdových potřeb a že zde nedochází k zbytečnému navýšení práv.

Obvykle mezi webovým serverem a back-endovým databázovým serverem neexistuje žádný vztah, protože sám aplikační server se chová jako jakýsi proxy server mezi oběma zmíněnými servery. Tím je zajištěno, že pokud se někdo dostane na webový server, nemůže přímo zaútočit proti databázovému serveru.

Ve virtuálním prostředí je to ale jiné. Webový server, aplikační server i databázový server mohou být všechny nainstalovány na jednom kusu železa. Lze tím dosáhnout úspory na nákladech, které se těžko odolává, a dokonce tím lze i navýšit výkon. Ovšem jak říkali přednášející na konferenci, pokud nemáte nástroje na potřebné oddělení funkčnosti a vazeb ve virtuálním prostředí, můžete se dostat do potíží.

Na konferenci se o virtualizačních konceptech centrálního řídícího serveru (někdy nazývaného jako hypervizor) hodně hovořilo. Hypervizorem zde bylo myšleno řídící centrum pro virtuální prostředí vytvořené na jednom jediném kusu hardwaru. Každý, kdo by byl schopen kompromitovat hypervizora, by principiálně získal kontrolu nad množstvím zdrojů, která se na tomto jediném kusu hardwaru nacházejí a které jednotlivá virtuální prostředí pro svou činnost potřebují. Jinými slovy, omezte přístup na hypervizor, jinak pocítíte důsledky.

Povídání o CMDB
Výběr dalšího tématu, o které jsem se zajímal, byl celkem přirozený, jelikož jsem ve fázi příprav strategie managementu konfigurací v naší firmě. Databáze pro řízení konfigurací (CMDB, Configuration Management DataBase) je centrálním zdrojem informací o veškerém IT majetku firmy.

Dříve jsme pro takový druh informací používali tabulky spreadsheetů (někdy i databáze), přičemž data jsme vkládali v souvislosti s jednotlivými položkami jako jsou například operační systém, úroveň patchů, velikost harddisku, objem paměti RAM, umístění v rozváděči či klíčové aplikace.
Dnešní systémy CMDB jsou ale úplně jiné. Poté, co vložíte základní data do systému, CMDB vám umožní získat podrobné informace třeba k registrům operačního systému Windows, souborům typu crontab v Unixu nebo třeba i indikátory o tom, že se systémové účty Windows nemohou interaktivně přihlašovat k serveru.

Na mnou navštíveném veletrhu bylo hodně dodavatelů řešení CMDB; zjistil jsem, že většina z nich při sběru dat využívá jeden z těchto dvou způsobů: Buď se CMDB přímo připojí ke konkrétnímu zdroji, nebo rozesílá malého softwarového agenta, který konfigurační parametry sbírá a posílá je do centrálního CMDB serveru. Z toho, co jsem viděl, se zdá, že tato technologie je stále ještě v plenkách, ale nabídky některých výrobců jako třeba CA už byly celkem rozsáhlé.

Vzhledem k tomu, že jsem měl možnost na konferenci o CMDB hovořit s různými lidmi, je mi jasné, že zavedení této technologie bude mít cenu jen tehdy, pokud vynaložíme úsilí i na nakonfigurování a správu CMDB infrastruktury. To by jsme si ale na sebe vzali pořádný závazek, jelikož v současnosti máme více než 400 produkčních serverů s různými operačními systémy počínaje Windows NT a Windows 2003 Server a konče různými verzemi Unixu a Linuxu. Ruční sběr konfiguračních položek by zabral opravdu hodně času i kapacity; podobné úsilí by navíc museli vyvinout i programátoři při tvorbě skriptů.

Také mi vyhovuje, že systémy CMDB lze využít i pro nastavení vztahů s dalšími zdroji, například router bude možné zobrazit ve vztahu k různým serverům. Pokud by pak bylo potřeba provést na routeru změny, měli bychom o těchto vazbách informaci předem a mohli si dát pozor na možné dopady na příslušných serverech.

Z pohledu bezpečnosti a řízení rizik může být technologie CMDB použita k indikaci změn oproti normálu na systémových souborech důležitých pro bezpečnost a k ověřování jednotlivých zařízeních, zda splňují požadované konfigurace.

Vybaven vědomostmi, které jsem nasbíral na své cestě do Las Vegas, se nyní budu snažit přesvědčit vyšší management, aby zahrnul projekt CMDB do rozpočtu. A teď, když vím, že na zmíněné konferenci se scházejí nejlepší odborníci na současná témata, zamyslím se i nad tím, jestli nevložit do rozpočtu na příští rok také další výlet do Las Vegas.