De fleste it-afdelinger ved godt, at de bør patche mere systematisk. Det er ikke ny viden. Alligevel er reaktiv og ustruktureret patching fortsat normen i mange organisationer — ikke fordi it-chefen er ligeglad, men fordi patching er tidskrævende, forbundet med nedetidsrisiko og ofte nedprioriteret til fordel for opgaver, der opleves som mere presserende.
NIS2-direktivet ændrer den kalkule. Direktivet stiller konkrete krav om systematisk risikostyring og forretningskontinuitet — og patch management er en direkte del af det. En virksomhed, der ikke kan dokumentere sin patchpraksis, opfylder ikke NIS2. Det er ikke en grå zone — det er et krav.
Her forklarer vi, hvad der konkret skal til for at gøre patch management til en driftsdisciplin frem for en brandslukning — med Red Hat Enterprise Linux og Red Hat Satellite som det tekniske fundament.
Problemet med reaktiv patching
Reaktiv patching er ikke en strategi. Det er fravær af en strategi — og det har konkrete konsekvenser.
Konsekvenserne ser typisk sådan ud i praksis:
- Sikkerhedshuller vokser stille: Kritiske patches udsættes, fordi der ikke er tid eller overblik. Angribere udnytter aktivt kendte, upatchede sårbarheder — og det tager gennemsnitligt 15 dage fra en sårbarhed offentliggøres, til den udnyttes aktivt
- Frygt for nedetid lammer beslutningen: Mange it-afdelinger undgår patching af produktionssystemer, fordi de ikke har testet patches i et kontrolleret miljø. Resultatet er systemer, der kører forældede versioner måneder — eller år — efter, at kritiske rettelser er tilgængelige
- Ingen dokumentation — ingen compliance: Kan I ikke bevise, hvornår et system sidst blev patchet og hvilke patches der er rullet ud, har I ikke et NIS2-compliant setup. En audit-log er ikke valgfrit — det er et krav
- Manuel patching skalerer ikke: Med mange RHEL-servere er manuel patching en tidssluger og en fejlkilde. Jo flere systemer, jo større risiko for inkonsistente konfigurationer og oversete patches
Patching er ikke et projekt, der afsluttes. Det er en løbende driftsproces — og den kræver de rigtige værktøjer.
RHEL som det rette fundament
Red Hat Enterprise Linux er enterprise-operativsystemet, der er designet til stabil, sikker og langvarig drift. RHEL-subscriptionen giver adgang til:
- Sikkerhedsopdateringer og fejl, kategoriseret som kritiske, vigtige, moderate og lave efter CVE-score
- Udvidet livscyklussupport — RHEL-versioner supporteres i op til 10 år, med mulighed for udvidet support herefter
- Adgang til Red Hat’s sikkerhedsteam og sårbarhedsdatabase
- Understøttelse på tværs af fysiske servere, virtuelle maskiner og cloud-miljøer
RHEL er fundamentet — men subscription alene er ikke nok til at gøre patch management til en velfungerende driftsdisciplin. Det kræver Satellite og Ansible.
Red Hat Satellite: Centraliseret livscyklusstyring for RHEL
Red Hat Satellite — inkluderet i Red Hat Smart Management — er den platform, der omsætter RHEL-subscription til struktureret og auditbar drift. Satellite giver ét samlet kontrolpunkt for provisionering, patching, konfiguration og compliance på tværs af hele RHEL-serverparken.
De centrale kapabiliteter i Satellite er:
- Content Views: Definer præcis hvilke patches og pakker, der er godkendt til hvilke miljøer — development, test og produktion. Patches flyttes kontrolleret gennem miljøerne, og produktion opdateres aldrig uden at have passeret test
- Errata management: Satellite giver et komplet overblik over tilgængelige sikkerhedsrettelser, fejlrettelser og forbedringer — kategoriseret og prioriteret. I kan filtrere på kritiske patches og handle hurtigt, når det er nødvendigt
- Livscyklusstyring: Styr RHEL-systemernes livscyklus fra provisionering til dekommissionering fra ét interface — med fuld historik
- Compliance og auditspor: Satellite logger præcis, hvad der er rullet ud hvornår og på hvilke systemer. Det er den dokumentation, der holder ved en NIS2-gennemgang — og som viser tilsynsmyndighederne, at patch management er en planlagt og verificeret proces
Satellite og Ansible i kombination
Satellite styrer indholdet og livscyklussen. Ansible eksekverer ændringerne. Tilsammen giver de en fuldt automatiseret patch-proces, der kan planlægges, verificeres og dokumenteres.
Et typisk automatiseret patch-forløb ser sådan ud:
- Satellite identificerer tilgængelige patches og kategoriserer dem efter kritikalitet
- Patches godkendes til et testmiljø via Content Views og valideres automatisk
- Ansible-playbooks kører patching af produktionssystemerne i planlagte vedligeholdsvinduer
- Satellite logger resultatet og opdaterer compliance-status — klar til audit
Det er denne kombination, der løfter patch-management fra en ad hoc-opgave til en dokumenteret og reproducerbar driftsdisciplin.
NIS2 og patch-management: Hvad direktivet faktisk kræver
NIS2’s artikel 21 stiller krav om tekniske og organisatoriske foranstaltninger til risikostyring — herunder systematisk håndtering af sårbarheder og sikkerhedsopdateringer. Det er ikke en vag henstilling. Det er et konkret krav, der forudsætter:
- En dokumenteret politik for patch management og sårbarhedshåndtering
- En verificerbar proces for identifikation, prioritering og udrulning af patches
- Et auditspor, der kan fremvises ved tilsyn — med datoer, systemer og patchhistorik
- Evne til at dokumentere, at kritiske patches rulles ud inden for en rimelig tidsramme
RHEL og Satellite giver de tekniske forudsætninger for at opfylde disse krav.
Fire spørgsmål, der er værd at stille jer selv
Patch management lyder ofte simpelt på papiret. I praksis er det her, det typisk begynder at skride:
- Har I en patchpolitik, der rent faktisk bliver brugt — og som beskriver hvornår og hvordan patches rulles ud?
- Kan I dokumentere, hvad der er blevet patchet (og hvornår) det seneste år?
- Har I et sted at teste patches, inden de rammer produktion?
- Er processen automatiseret — eller afhænger den af, at nogen husker det?
Hvis I tøver ved et eller flere af svarene, er I ikke alene. Men det er også her, forskellen ligger mellem en proces, der ser fin ud på papiret — og en, der faktisk fungerer i driften.
Og det er typisk den forskel, der bliver synlig, når krav som NIS2 rammer.
Hvordan kommer man derhen i praksis?
Når patch management skal fungere i driften — ikke bare på papiret — handler det typisk om at få styr på tre ting: overblik, struktur og automatisering.
I et RHEL-miljø ser vi ofte, at det kræver:
- Et klart billede af, hvordan der patches i dag — og hvor det halter i forhold til interne krav og fx NIS2
- En struktur for, hvordan patches styres og rulles ud (fx med lifecycle environments og content views)
- Automatisering, så det ikke afhænger af enkeltpersoner eller manuelle rutiner
- Dokumentation, der ikke skal samles i sidste øjeblik, men opstår som en del af processen
Teknologisk bliver det ofte bundet sammen med værktøjer som Red Hat Satellite, Smart Management og Ansible — men værktøjerne løser ikke problemet i sig selv. Det gør måden, de bliver brugt på.
Når det bliver gjort ordentligt, ligner det typisk et forløb som dette:
- Først et realistisk billede af nuværende praksis (ikke kun det, der står i dokumentationen)
- Derefter opsætning af en struktur, der passer til miljøet — ikke en standardskabelon
- Automatisering af patching i faste vinduer
- Opbygning af dokumentation og auditspor som en naturlig del af driften
- Og til sidst: en proces, der kan køre videre uden at være afhængig af enkeltpersoner
Patch management bliver sjældent en succes, fordi man vælger det rigtige værktøj. Det gør det, når det bliver en integreret del af driften.
Har I styr på, hvordan jeres patch management fungerer i praksis?
Vi tager gerne et kig på jeres nuværende setup og giver en konkret vurdering af, hvor det halter, og hvad der skal til for at få det til at fungere i driften. Ræk ud til Mads Andersen: