Har I sat en sikkerhedsindstilling i en politik, er det let at gå ud fra, at den gælder på alle maskiner. Det er ikke altid tilfældet, for en politik kan blive overskrevet af en anden, ramme forkert i strukturen eller være sat ud af kraft lokalt, og derfor skal en gennemgang se på den indstilling, der faktisk gælder på maskinen.
Forskellen mellem det tiltænkte og det effektive er en af de mest almindelige fejlkilder i en konfigurationsgennemgang. Den er også en af de letteste at rette, når den først er fundet.
Hvorfor forskellen opstår
En maskine får sine indstillinger fra flere steder. Det kan være politikker på forskellige niveauer i kataloget, en lokal opsætning på maskinen, et styringsværktøj fra skyen og indstillinger, en administrator har sat i hånden under fejlsøgning. Når flere kilder siger noget om samme indstilling, er det en bestemt rækkefølge, der afgør, hvilken der vinder.
Typiske årsager til, at den tiltænkte indstilling ikke gælder, er fx disse:
- En anden politik med højere forrang sætter en anden værdi.
- Politikken er knyttet til en del af strukturen, hvor maskinen ikke ligger.
- Politikken er filtreret, så den kun gælder bestemte grupper, og maskinen eller brugeren er ikke med.
- Maskinen har ikke hentet politikken, fx fordi den sjældent er på netværket.
- En lokal ændring er lavet efter politikken og er ikke blevet overskrevet.
Ingen af dem kan ses ved at læse politikken. De kan kun ses på maskinen.
Hvad NIST og forordningen siger
NIST skriver, at en gennemgang af dokumenter ikke sikrer, at sikkerhedskontrollerne er gennemført korrekt (SP 800-115 fra 2008, afsnit 3.1). En politik i kataloget er i den forstand et dokument. Den beskriver, hvad der er tiltænkt.
Blandt de typiske grundårsager til svagheder nævner NIST mangel på baselines, fx uensartede sikkerhedsindstillinger på systemer, der burde være ens (afsnit 7.3). Det er netop det, der opstår, når en politik ikke slår igennem alle steder.
Bilaget til forordning 2024/2690 forlanger, at de udbydere, der er omfattet, kan gennemtvinge de sikre indstillinger, de har besluttet, med faste processer og egnede værktøjer (punkt 6.3.2, litra b). Det er netop det, der kan efterprøves på maskinen. Uden for forordningens kreds er punktet en målestok.
Sådan findes den effektive indstilling på Windows
På Windows kan den indbyggede kommando gpresult vise det, Microsoft kalder Resultant Set of Policy. Ifølge Microsofts dokumentation viser den de politikindstillinger, som computeren faktisk fik anvendt for en bestemt bruger, da brugeren loggede på. Kommandoen kan give et resumé, en detaljeret visning eller en HTML-rapport, og den kan afgrænses til bruger eller computer.
Rapporten viser også, hvilke politikker der er anvendt, og hvilke der er filtreret fra. Det er ofte her, forklaringen på en afvigelse står.
For andre platforme og for styring fra skyen findes der tilsvarende muligheder, men dem beskriver vi ikke her. Slå op i producentens dokumentation, hvordan den gældende indstilling vises.
En fremgangsmåde i tre trin
Det følgende er praksis:
- Træk den tiltænkte indstilling. Udtræk politikkerne med de værdier, de sætter, og hvilke dele af strukturen de gælder for.
- Træk den effektive indstilling. Kør en rapport over den gældende politik på et udvalg af maskiner pr. rolle, fx én maskine fra hver afdeling og én, der sjældent er på netværket.
- Sammenlign. Hvor de to ikke stemmer, find kilden til forskellen i rapporten over anvendte og frafiltrerede politikker.
Sammenligningen giver tre slags resultater: indstillinger, der gælder som tiltænkt; indstillinger, der er overskrevet af en anden politik; og indstillinger, der er ændret lokalt. Den første gruppe er i orden. De to andre er fund, medmindre afvigelsen står på undtagelseslisten.
Lokale undtagelser
Nogle maskiner skal have andre indstillinger end resten. Et fagsystem kan kræve en lempelse, eller en maskine kan have en særlig rolle. Det er i orden, når undtagelsen er bevidst. Problemet opstår, når undtagelsen er lavet i hånden på maskinen og ikke står nogen steder.
En god tommelfingerregel er, at undtagelser laves som politik og ikke som lokal ændring, og at de står på undtagelseslisten med begrundelse. Så kan de ses i det tiltænkte, og forskellen mellem tiltænkt og effektiv bliver lille.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at driften trækker rapporter over gældende indstillinger fra et udvalg af maskiner og sammenligner dem med politikkerne. Med en fast fremgangsmåde tager det ikke lang tid.
Uden den kontrol tror I, at en indstilling gælder, fordi den står i politikken. Det kan holde i årevis, indtil nogen opdager, at netop de maskiner, der blev ramt af en hændelse, aldrig fik den.
Det skal I lade være med
- At bruge politikken som bevis for indstillingen på maskinen · træk den effektive værdi.
- At lave undtagelser som lokale ændringer · lav dem som politik med begrundelse.
- At udvælge kun maskiner, der altid er på netværket · tag også dem med, der sjældent er.
Det skal gennemgangen kunne vise
- ☐ Udtræk af politikkerne med værdier og gyldighed.
- ☐ Rapporter over gældende indstillinger fra et udvalg af maskiner pr. rolle.
- ☐ En liste over afvigelser mellem tiltænkt og effektiv med årsag.
- ☐ Lokale undtagelser på undtagelseslisten med begrundelse.
Kilder
- Microsoft Learn, gpresult, opdateret 22. oktober 2025, læst 13. november 2026.
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, september 2008, afsnit 3.1 og 7.3, læst 13. november 2026.
- Gennemførelsesforordning (EU) 2024/2690, bilaget, punkt 6.3.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg én vigtig sikkerhedsindstilling, og sammenlign den tiltænkte værdi i politikken med den gældende på fem maskiner.
Læs også: Windows-servere holdt op mod en baseline · Klienternes opsætning
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
