Zastaralý software a neznámý stav infrastruktury představují pro firmy větší riziko, než si mnohdy uvědomují. Bezpečnostní architekt MasterDC Petr Bělousov v rozhovoru popisuje, s čím se při správě IT u zákazníků nejčastěji setkává, proč se firmy aktualizací obávají a jak postupně dostat technický dluh pod kontrolu.
Jaké problémy dnes nejčastěji řešíte při správě IT infrastruktury firem?
Jedním z problémů, se kterými se setkáváme dlouhodobě a opakovaně, je odkládání aktualizací. Ty totiž obvykle vyžadují restart. Samotné naplánování servisního okna přitom nebývá problém. U některých prostředí ale existují oprávněné obavy z toho, co po restartu nastane. Server nenaběhne vůbec, spustí se jen část služeb, nepřipojí se disky nebo síťová úložiště. Odstávka se protahuje, zaměstnanci nemohou pracovat a firma přichází o peníze.
Co za těmito obavami stojí?
Především to, že nikdo přesně neví, v jakém stavu systémy jsou. To je samo o sobě známka technického dluhu.
Když v MasterDC přebíráme do správy IT prostředí zákazníků, skoro vždycky narazíme na něco, co chybí v dokumentaci nebo o čem firma nemá přehled. Správci se ve firmách mění a průběžně přibývají ruční úpravy, které se nikam nezapisují. Některé systémy běží dál bez podpory, protože by jejich upgrade vyžadoval rozsáhlejší změny. Podobné problémy většinou nevznikají z nedbalosti. Jde spíš o důsledek toho, že firma roky řeší hlavně každodenní provoz a na systematickou údržbu jí nezbývá kapacita.
V IT se často říká, že do toho, co funguje, je lepší nezasahovat. Není na tom kousek pravdy?
Určitě je. Nemá smysl nasazovat každou aktualizaci okamžitě a bez rozmyslu, třeba v pátek odpoledne. Dlouhodobé odkládání změn ale znamená, že firma postupně ztrácí možnost plánovat, kdy a jak se s nimi vypořádá. Bezpečnostní problém pak může vyžadovat neplánovaný zásah v době, kdy na něj není připravená.
Rozdíl dobře ilustrují nedávno odhalené zranitelnosti PHP2Shell. U podporovaných verzí PHP stačilo nasadit bezpečnostní opravu z repozitáře. U nepodporovaných byla situace složitější. Vývojáři museli buď narychlo ověřit kompatibilitu s novější verzí a upravit aplikaci, nebo doufat, že někdo vydá opravu i pro jejich starší verzi. Řešení tak mohlo zabrat podstatně víc času a služby mezitím zůstávaly zranitelné. Dočasné opravy totiž riziko pouze zmírňují, ale neodstraňují.
Co byste doporučil firmě, která má v údržbě IT velké mezery a chce to napravit?
Nejdřív by si měla zmapovat, co vlastně provozuje. Zjistit, které systémy už nejsou podporované, na čem jsou závislé a jaké technologie využívají.
U starších aplikací nejprve prověřujeme jejich kompatibilitu s novějšími technologiemi, případně hledáme vhodnou náhradu. Potom určujeme priority podle toho, jaká rizika jednotlivé systémy představují. Zajímá nás například, zda jsou dostupné z internetu nebo obsahují známé zranitelnosti.
Nesnažil bych se všechno modernizovat najednou. Lepší je rozdělit změny do zvládnutelných kroků, otestovat je a teprve potom postupně zavádět do ostrého provozu.
Může firma zajistit, aby se do podobné situace nikdy nedostala?
Problémy úplně vyloučit nejde, ale to riziko jde výrazně snížit. Pomáhá standardizace a automatizace. I když firma spravuje jen pár serverů, měla by se snažit sjednotit alespoň základní nastavení systémů.
V MasterDC v rámci služby Managed Enterprise spravujeme přes tisíc serverů. Potřebujeme proto přesně vědět, jak jsou nastavené, a mít možnost jejich konfiguraci kdykoli zopakovat nebo plošně změnit. V podobných případech už jsou nezbytné automatizační nástroje, například Ansible. Konfigurace a postupy díky nim nejsou závislé jen na znalostech jednoho člověka a při obnově nebo změnách se můžeme opřít o známý, zdokumentovaný stav. Stejný přístup nám umožňuje připravit testovací prostředí a ověřit v něm aktualizaci ještě před nasazením.
Co když firma při revizi IT zjistí, že některé systémy už nemůže aktualizovat?
Ano, to se může stát. Aktualizace nezávisí jen na správci IT. Novější verze může vyžadovat úpravy aplikace od externího vývojáře. Ten už ale nemusí software dál rozvíjet nebo pro něj poskytovat podporu. Proto je důležité domluvit se s dodavatelem už při pořízení softwaru na zajištění průběžných aktualizací.
Pokud už systém aktualizovat nelze, firma by měla naplánovat jeho náhradu nebo migraci. Do té doby je třeba omezit jeho vystavení vnějším hrozbám. Pomoci může například omezení přístupu z internetu, nastavení firewallu nebo nasazení WAF, který filtruje škodlivé požadavky na webovou aplikaci.
Na co dalšího si dát pozor při spuštění projektu?
Určitě pečlivě vybrat technologie, na kterých řešení poběží. Zajímat by nás měla hlavně délka podpory a komunita kolem technologie. Příkladem je Debian, který má širokou uživatelskou i vývojářskou základnu a pravidelně vydává bezpečnostní aktualizace.
Firmy by navíc měly počítat s tím, že se mohou změnit i podmínky dodavatelů. Konec CentOS 8 i změny kolem VMware ukázaly, že někdy se musí náhrada hledat mnohem dřív, než se původně plánovalo. Právě proto jsme například u návrhu architektury nové cloudové platformy v MasterDC dbali na to, aby byla technologicky nezávislá.
Co taková technologická nezávislost obnáší?
Především to, že na sobě nejsou pevně závislé jednotlivé vrstvy infrastruktury, tedy hardware, virtualizace, úložiště a síť. Když některá z nich doslouží nebo dodavatel změní podmínky, vymění se jen konkrétní část, ne celé řešení.
Stejným způsobem je dobré oddělit i jednotlivé části aplikací. Když například webový server a databáze běží na samostatných virtuálních strojích, lze je aktualizovat nezávisle a případný průnik do jedné části neohrozí automaticky celý systém. Pokud virtualizace běží na více fyzických serverech, je možné hardware nebo hypervizor aktualizovat bez odstávky, protože se virtuální stroje dočasně přesunou na jiný server. Takový návrh vyžaduje na začátku více plánování, ale následnou údržbu výrazně usnadní.
Jak by měly postupovat firmy, které si takto robustní infrastrukturu nemohou dovolit?
Clustery s virtualizací se nasazují v kritických provozech, kde výpadek může ovlivnit stovky zákazníků nebo další firemní systémy. Menší firmy se bez nich obejdou, ale měly by vědět, za jak dlouho dokážou obnovit provoz ze záloh.
Když se zákazníky řešíme dostupnost, vědí, že delší výpadek znamená větší komplikace. Často ale nemají přesně určeno, jak dlouhý výpadek je pro ně ještě přijatelný, a délku obnovy spíše odhadují. Až při skutečném problému pak zjistí, že obnova trvá mnohem déle, než čekali. Vzhledem k rostoucímu počtu kyberútoků i požadavkům NIS2 na kontinuitu provozu bych proto doporučil hlavně pravidelně obnovu testovat.
Co je tedy podle vás základem dlouhodobě spolehlivého IT?
Obavy z aktualizací a restartů obvykle vyplývají z toho, že firma své prostředí dostatečně nezná. Hned na začátku by proto měla zvolit technologie, kterým rozumí a dokáže je spravovat bez závislosti na jediném člověku. Lépe si pak udrží přehled v tom, jaké systémy provozuje, na čem závisí a jak je obnovit.
Průběžnou údržbu usnadní dobře nastavený monitoring, který upozorní na podstatné problémy. Například nedostatek výkonu, místa, chybu v nové verzi aplikace, problémy po aktualizaci, ale třeba i cílený útok. Výstupy z monitoringu mohou navíc posloužit také při auditu nebo řešení bezpečnostního incidentu.
Chápu, že ne každá firma má vlastní kapacity na to, aby se dokázala o všechny tyto oblasti postarat. S tím ale můžeme pomoci třeba my v MasterDC. Spolehlivé IT zkrátka neznamená nenarážet na problémy, ale umět jim předcházet a případně na ně rychle reagovat.
ČLÁNKY DO MAILU