Patch management (správa záplat)

Příklady z praxe

1. 01

   Log4Shell v interní aplikaci

   Po zveřejnění kritické chyby v knihovně Log4j firma zjistila, že knihovnu obsahuje pět aplikací, ale jen dvě z nich byly v evidenci. Zbytek se našel až skenem artefaktů v repozitáři. Nasazení opravené verze trvalo dvě hodiny, dohledání zasažených systémů dva dny. To je typický poměr: nejdražší částí patch managementu je inventář, ne instalace.

2. 02

   Nezapočítaný restart po aktualizaci jádra

   Automatická aktualizace nainstalovala nové jádro, ale server běžel dál na starém, protože se nikdo neodvážil restartovat produkční databázi. Kontrola verze balíčku hlásila opravený stav, kontrola běžícího jádra ne. Rozdíl obou hodnot je jednoduchý indikátor, který patří do monitoringu.

   # nainstalovaná verze vs. skutečně běžící jádro
   rpm -q --last kernel | head -1
   uname -r
   
   # Debian/Ubuntu: příznak, že je potřeba restart
   ls /var/run/reboot-required 2>/dev/null && echo "restart ceka"

Časté omyly

MýtusStačí zapnout automatické aktualizace a máme hotovo.

Ve skutečnostiAutomatické aktualizace pokrývají operační systém a balíčky distribuce, ale ne aplikační závislosti, firmware, síťové prvky ani systémy, na které agent nedosáhne. Bez inventáře a ověření navíc nikdo neví, kolik zařízení aktualizace skutečně dokončila.

MýtusVysoké CVSS skóre znamená, že se musí opravit okamžitě.

Ve skutečnostiCVSS měří závažnost chyby, ne riziko v konkrétním prostředí. Zranitelnost v komponentě, která není nainstalovaná nebo je nedostupná zvenčí, může počkat, zatímco střední chyba s veřejně dostupným exploitem na internetově exponované službě je naléhavější.

MýtusKontejnery se nezáplatují, protože jsou izolované.

Ve skutečnostiKontejner sdílí jádro hostitele a jeho image obsahuje běžné systémové knihovny se stejnými zranitelnostmi jako klasický server. Rozdíl je pouze ve způsobu opravy: místo aktualizace běžící instance se přestaví image a nasadí nová verze.

Časté dotazy

Jak často by se měly záplaty nasazovat?

Frekvence patch managementu se obvykle řídí kombinací pravidelného cyklu a mimořádných zásahů. Běžnou praxí je měsíční okno navázané na vydávací kalendář dodavatelů, doplněné o zrychlený postup pro kritické chyby s aktivně zneužívaným exploitem, kde se lhůta počítá v hodinách či jednotkách dní. Kratší cyklus není vždy lepší: příliš časté zásahy do produkce zvyšují riziko výpadku a únavu týmu. Rozumnější je zvolit interval podle expozice systému, tedy častěji u služeb dostupných z internetu a volněji u izolovaných interních strojů.

Co dělat se systémem, který opravit nelze?

Systém bez dostupné opravy, typicky software po konci podpory nebo certifikovaný přístroj, patří do evidence výjimek se jmenovaným vlastníkem a datem revize. Riziko se snižuje kompenzačními opatřeními: oddělením do vlastního síťového segmentu, omezením přístupu na nezbytné adresy, virtual patchingem na aplikační bráně nebo webovém firewallu a zvýšeným monitoringem. Výjimka není trvalé řešení, měla by mít definovaný plán migrace nebo výměny, jinak se z ní stane skrytý dluh, který si organizace uvědomí až při incidentu.

Kdo za patch management ve firmě odpovídá?

Odpovědnost za patch management bývá rozdělená, což je zdroj většiny mezer. Bezpečnostní tým typicky sleduje zranitelnosti a stanovuje lhůty, provozní nebo platformový tým aktualizace nasazuje, vývojáři řeší závislosti vlastních aplikací a vlastník aplikace schvaluje odstávku. Aby to fungovalo, potřebuje každý systém v inventáři jmenovaného vlastníka. Bez toho zůstávají nejrizikovější stroje bez péče, protože se o ně formálně nikdo nestará. V menších firmách roli často pokrývá externí poskytovatel správy, pak je nutné mít rozsah služby a lhůty ve smlouvě.

Jak doložit auditorovi, že patch management funguje?

Auditor obvykle chce vidět čtyři věci: schválenou politiku s definovanými lhůtami podle závažnosti, úplný inventář aktiv s vlastníky, záznamy o nasazení konkrétních oprav včetně schválení změny a důkaz o následném ověření, typicky výstup ze skeneru zranitelností před opravou a po ní. Doplňkem je evidence výjimek s odůvodněním a datem revize. Samotné tvrzení, že jsou zapnuté automatické aktualizace, jako důkaz nestačí, protože nedokládá pokrytí ani úspěšnost nasazení napříč prostředím.

Zdroje

1. NIST Special Publication 800-40: Guide to Enterprise Patch Management Planning(otevře se v novém okně)NIST, 2022
2. OWASP Top Ten(otevře se v novém okně)OWASP Foundation
3. Directive (EU) 2022/2555 (NIS 2)(otevře se v novém okně)Úřad pro publikace EU, 2022
4. Docker Docs: Building best practices(otevře se v novém okně)Docker, Inc.

Související pojmy

• CVECVE je veřejný katalog konkrétních zranitelností softwaru a hardwaru, ve kterém každá chyba dostane jednoznačné číslo ve tvaru CVE-rok-pořadí. Identifikátor slouží jako společný odkaz pro výrobce, bezpečnostní skenery, databáze i administrátory, takže všichni mluví prokazatelně o téže chybě bez ohledu na to, jak ji kdo pojmenoval.
• ZranitelnostZranitelnost je slabé místo v softwaru, hardwaru, konfiguraci nebo procesu, které může útočník zneužít k porušení důvěrnosti, integrity nebo dostupnosti systému. Sama o sobě ještě není útokem: riziko vzniká až kombinací zranitelnosti, dostupné cesty ke zneužití, hodnoty ohrožených dat a pravděpodobnosti, že někdo slabinu využije.
• Bezpečnostní auditBezpečnostní audit je systematické prověření toho, zda aplikace, infrastruktura, procesy a lidé chrání data před reálnými riziky. Výsledek obvykle obsahuje zjištění, důkazy, hodnocení závažnosti a doporučené kroky, podle kterých tým opravuje slabá místa a dokládá soulad s interními pravidly nebo regulací.
• Zero-day zranitelnostZero-day zranitelnost je bezpečnostní chyba v softwaru nebo hardwaru, pro kterou v okamžiku zneužití neexistuje veřejně dostupná oprava ani spolehlivá signatura. Útočník tak může využít náskok před výrobcem, správci i bezpečnostními nástroji; riziko trvá hlavně do vydání patche, obchvatného opatření nebo vypnutí zasažené funkce.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• AcquirerAcquirer je finanční instituce nebo platební poskytovatel, který obchodníkovi umožňuje přijímat karetní platby a předává transakce do karetních schémat. V online platbách stojí mezi platební bránou, vydavatelem karty a obchodníkem, zajišťuje autorizaci, zúčtování, vyplacení peněz a část řízení rizik.
• AI etikaAI etika je obor, který zkoumá, jaké dopady mají systémy umělé inteligence na lidi, a formuluje pravidla pro jejich návrh, trénink a provoz. Řeší zaujatost dat, transparentnost rozhodování, ochranu soukromí, odpovědnost za chybu i bezpečnost modelu. Ve firemní praxi se promítá do interních politik, dokumentace modelů a povinností podle regulace typu AI Act.
• API GatewayAPI Gateway je vstupní vrstva mezi klientem a sadou backendových služeb, která přijímá požadavky, směruje je na správné API, vynucuje bezpečnostní pravidla a často řeší limity, logování nebo transformace odpovědí. Pomáhá skrýt vnitřní strukturu systému a sjednotit chování pro web, mobilní aplikaci i partnery.