CIS Benchmark-compliance med OpenSCAP og Ansible: Din komplette guide til Linux-servere

Introduktion

Compliance er ikke længere noget, man klarer med en tjekliste og en kop kaffe en fredag eftermiddag. I 2026 forventer regulatorer, revisorer og sikkerhedsteams, at Linux-servere kan scannes, rapporteres og udbedres automatisk — helst som en integreret del af din infrastruktur-pipeline. Og alligevel kæmper overraskende mange organisationer stadig med at få det til at fungere i praksis.

Det er der en god grund til. De fleste guider derude er enten forældede, fragmenterede eller fokuserer kun på ét aspekt af processen.

Denne guide samler hele workflowet ét sted: fra installation af OpenSCAP og SCAP Security Guide over scanning mod CIS Benchmarks til automatiseret udbedring med Ansible. Alle kommandoer er testet på RHEL 9 og Ubuntu 24.04 — de to distributioner, der dominerer produktionsmiljøer lige nu. Så lad os komme i gang.

Hvad er CIS Benchmarks?

CIS Benchmarks (Center for Internet Security) er den globale standard for sikkerhedskonfiguration af IT-systemer. De indeholder hundredvis af specifikke konfigurationsanbefalinger, som er udviklet og peer-reviewed af sikkerhedseksperter fra både offentlige og private organisationer verden over.

Kort sagt: hvis du driver Linux-servere i produktion, er CIS Benchmarks det nærmeste, du kommer en universelt accepteret "sikkerhedstjekliste".

Level 1 vs. Level 2

CIS Benchmarks opdeles i to profiler:

• Level 1 (Baseline): Grundlæggende sikkerhedsanbefalinger, der kan implementeres på enhver server uden at påvirke funktionaliteten. Det er det anbefalede udgangspunkt for alle produktionsservere.
• Level 2 (Defense-in-Depth): Strengere konfigurationer til miljøer, hvor sikkerhed er altafgørende — typisk servere med følsomme data, PII eller regulatoriske krav. Level 2 kan påvirke ydeevne og funktionalitet, hvis det ikke implementeres med omhu (og det kræver virkelig omhu).

De seneste CIS-versioner i 2026 er v2.0.0 for RHEL 9, v4.0.0 for RHEL 8 og v1.0.1 for RHEL 10, alle tilgængelige via SCAP Security Guide version 0.1.80 og nyere.

Hvad er OpenSCAP?

OpenSCAP er en open source-implementering af SCAP (Security Content Automation Protocol) — en NIST-standard til automatiseret sårbarhedshåndtering og compliance-evaluering. Økosystemet består af flere værktøjer, og det er værd at kende dem:

• oscap — kommandolinjeværktøjet til scanning og rapportering (det her er dit daglige arbejdsredskab)
• SCAP Security Guide (SSG) — sikkerhedspolitikker i datastream-format med færdige profiler til CIS, DISA STIG, PCI-DSS med flere
• SCAP Workbench — en grafisk brugerflade til tilpasning af politikker
• oscap-im — et nyere værktøj til hærdning af bootbare container-images (Image Mode RHEL)

Men det bedste ved OpenSCAP? Det kan ikke kun scanne. Det kan også generere Bash-scripts og Ansible-playbooks til automatisk udbedring af de fundne afvigelser. Det er denne kombination af scan, rapportering og automatiseret remediation, der gør det til et komplet compliance-værktøj — og ærligt talt, det er ret imponerende for et open source-projekt.

Installation og opsætning

Installationen er heldigvis ret ligetil på begge distributioner. Her er hvad du skal bruge.

RHEL 9 / AlmaLinux 9 / Rocky Linux 9

# Installer OpenSCAP-scanner og SCAP Security Guide
sudo dnf install -y openscap-scanner scap-security-guide

# Verificer installation
oscap --version
rpm -q scap-security-guide

Ubuntu 24.04

# Installer OpenSCAP og sikkerhedsguider
sudo apt update
sudo apt install -y libopenscap8 openscap-scanner ssg-base ssg-ubuntu

# Verificer installation
oscap --version
dpkg -l | grep ssg

Vigtige filstier efter installation

Når pakkerne er installeret, finder du sikkerhedsindholdet i følgende mapper. Det er en god idé at huske disse stier — du får brug for dem igen og igen:

# SCAP datastream-filer (bruges til scanning)
/usr/share/xml/scap/ssg/content/

# Færdige Ansible-playbooks til remediation
/usr/share/scap-security-guide/ansible/

# Bash-remediationsscripts
/usr/share/scap-security-guide/bash/

# Kickstart-filer til automatiseret installation
/usr/share/scap-security-guide/kickstart/

Tilgængelige CIS-profiler

Før du kører din første scanning, skal du vide, hvilke profiler der faktisk er tilgængelige. Brug følgende kommando til at liste alle profiler i en datastream-fil.

RHEL 9

# List alle tilgængelige profiler
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Du vil se profiler som:
#   xccdf_org.ssgproject.content_profile_cis_server_l1
#   xccdf_org.ssgproject.content_profile_cis_server_l2
#   xccdf_org.ssgproject.content_profile_cis_workstation_l1
#   xccdf_org.ssgproject.content_profile_cis_workstation_l2
#   xccdf_org.ssgproject.content_profile_stig
#   xccdf_org.ssgproject.content_profile_pci-dss

Ubuntu 24.04

# List profiler for Ubuntu
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

# Typiske profiler:
#   xccdf_org.ssgproject.content_profile_cis_level1_server
#   xccdf_org.ssgproject.content_profile_cis_level2_server

Din første CIS-compliance-scanning

Nu kommer den sjove del — den faktiske scanning. Her kører vi en fuld CIS Level 1-scanning og genererer både en XML-resultatfil og en HTML-rapport, som du kan åbne i browseren.

Scanning på RHEL 9

# Opret mappe til rapporter
sudo mkdir -p /var/log/compliance

# Kør CIS Level 1 Server-scanning
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /var/log/compliance/cis-l1-results-$(date +%Y%m%d).xml \
  --report /var/log/compliance/cis-l1-report-$(date +%Y%m%d).html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Scanning på Ubuntu 24.04

# Kør CIS Level 1 Server-scanning
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /var/log/compliance/cis-l1-results-$(date +%Y%m%d).xml \
  --report /var/log/compliance/cis-l1-report-$(date +%Y%m%d).html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

Forståelse af scanningsresultater

Når scanningen er færdig, ser du et resumé i terminalen med antallet af regler, der er bestået (pass), fejlet (fail), ikke gældende (notapplicable) og ikke kontrolleret (notchecked). HTML-rapporten giver en langt mere detaljeret visning med:

• En compliance-score i procent
• Hver regel med status (pass/fail), beskrivelse og referencer
• Specifikke udbedringsinstruktioner for fejlede regler
• Links til relevante CIS-kontrolnumre

Bliv ikke skræmt, hvis din første scanning lander på 60-75 %. Det er helt normalt for en server med standardkonfiguration. Målet er typisk at nå over 90 % efter udbedring. Og 100 %? Det er sjældent realistisk eller nødvendigt — der vil næsten altid være bevidste undtagelser i dit miljø.

Automatiseret udbedring med Ansible

Det er her, det for alvor bliver interessant. Den virkelige kraft i OpenSCAP ligger i muligheden for at generere remedierings-playbooks direkte fra scanningsresultaterne. I stedet for manuelt at gennemgå hundredvis af findings (og vi har alle prøvet det), kan du automatisere udbedringen.

Metode 1: Generer Ansible-playbook fra scanningsresultater

Denne metode genererer en playbook, der kun indeholder tasks for de regler, der fejlede. Det er smart, fordi du ikke spilder tid på ting, der allerede er i orden:

# Generer Ansible-playbook fra scanningsresultater
sudo oscap xccdf generate fix \
  --fix-type ansible \
  --result-id "" \
  --output /tmp/cis-remediation.yml \
  /var/log/compliance/cis-l1-results-$(date +%Y%m%d).xml

# Se indholdet
cat /tmp/cis-remediation.yml | head -50

Metode 2: Brug færdige SSG-playbooks

SCAP Security Guide leveres med komplette, forudgenererede Ansible-playbooks for hver profil. Disse dækker alle regler i profilen — ikke kun de fejlede:

# RHEL 9 — CIS Level 1 Server
ls /usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml

# Anvend playbook lokalt
sudo ansible-playbook -i localhost, -c local \
  /usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml

Altid kør i check-mode først

Det her kan ikke siges tydeligt nok: kør aldrig remediation direkte på en produktionsserver uden at teste først. Bare lad være.

# Dry-run — vis hvad der ville ændres, uden at ændre noget
sudo ansible-playbook -i localhost, -c local \
  --check --diff \
  /tmp/cis-remediation.yml

Gennemgå outputtet grundigt. Automatiseret remediation kan have utilsigtede konsekvenser — for eksempel kan en regel deaktivere en service, som din applikation afhænger af. Personligt har jeg set det ske med NFS og DNS-services, og det er ikke sjovt at fejlfinde klokken tre om natten. Det er derfor, scan → review → test → anvend-workflowet er så vigtigt.

Den komplette workflow

Den anbefalede fremgangsmåde er en cyklisk proces, og det er værd at følge den slavisk — i hvert fald i starten:

1. Baseline-scanning: Kør den første scanning for at etablere et udgangspunkt
2. Gennemgå resultater: Identificer fejlede regler og vurder, hvilke der er relevante
3. Generer playbook: Opret en remedierings-playbook fra resultaterne
4. Review playbook: Fjern tasks, der ikke er relevante for dit miljø
5. Dry-run: Kør i check-mode og gennemgå ændringerne
6. Anvend: Kør playbooken uden check-mode i et testmiljø
7. Verificer: Kør scanningen igen og bekræft forbedret compliance
8. Dokumenter undtagelser: Registrer bevidste afvigelser med begrundelse

Tilpasning med tailoring-filer

Ikke alle CIS-regler giver mening i alle miljøer. Og det er helt okay. Med tailoring-filer kan du tilpasse, hvilke regler der evalueres, uden at ændre den originale sikkerhedspolitik.

Opret en tailoring-fil med SCAP Workbench

Den nemmeste metode er at bruge SCAP Workbench, som giver dig en grafisk brugerflade til at vælge og fravælge regler:

# Installer SCAP Workbench
sudo dnf install -y scap-workbench    # RHEL/Fedora
sudo apt install -y scap-workbench    # Ubuntu/Debian

# Start programmet
scap-workbench &

I SCAP Workbench kan du indlæse en datastream-fil, vælge en profil og derefter deaktivere eller aktivere individuelle regler. Resultatet gemmes som en XML-tailoring-fil, som du kan genbruge i alle fremtidige scanninger.

Brug tailoring-fil ved scanning

# Scanning med tilpasset profil
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1_customized \
  --tailoring-file /etc/openscap/cis-tailoring.xml \
  --results /var/log/compliance/cis-tailored-results.xml \
  --report /var/log/compliance/cis-tailored-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Autotailor fra kommandolinjen

For automatiserede pipelines er CLI-baseret tilpasning mere praktisk (og lettere at versionere i Git). Værktøjet autotailor (del af SSG) understøtter nu også JSON-tailoring-filer med flere profiler:

# Eksempel: Deaktiver specifik regel via autotailor
autotailor \
  --id-namespace org.ssgproject.content \
  --output /etc/openscap/cis-tailoring.xml \
  --profile cis_server_l1 \
  --unselect xccdf_org.ssgproject.content_rule_service_nfs_disabled \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Automatiserede ugentlige scanninger

Compliance er ikke en engangsøvelse. Det er en løbende proces, og jo før du accepterer det, jo lettere bliver det at håndtere. Opsæt automatiserede ugentlige scanninger med et simpelt script:

#!/bin/bash
# /usr/local/bin/weekly-cis-scan.sh
# Ugentlig CIS Level 1 compliance-scanning

REPORT_DIR="/var/log/compliance"
DATE=$(date +%Y%m%d-%H%M)
PROFILE="xccdf_org.ssgproject.content_profile_cis_server_l1"
DATASTREAM="/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml"
ADMIN_EMAIL="[email protected]"

mkdir -p "${REPORT_DIR}"

# Kør scanning
oscap xccdf eval \
  --profile "${PROFILE}" \
  --results "${REPORT_DIR}/cis-l1-${DATE}.xml" \
  --report "${REPORT_DIR}/cis-l1-${DATE}.html" \
  "${DATASTREAM}" 2>&1

# Udtræk statistik
PASS=$(grep -c 'result.*pass' "${REPORT_DIR}/cis-l1-${DATE}.xml" 2>/dev/null || echo "0")
FAIL=$(grep -c 'result.*fail' "${REPORT_DIR}/cis-l1-${DATE}.xml" 2>/dev/null || echo "0")

# Send notifikation
echo "CIS L1 Scan ${DATE}: ${PASS} bestået, ${FAIL} fejlet. Rapport: ${REPORT_DIR}/cis-l1-${DATE}.html" \
  | mail -s "CIS Compliance Rapport - $(hostname)" "${ADMIN_EMAIL}"

# Ryd op — behold kun de seneste 12 rapporter
ls -t "${REPORT_DIR}"/cis-l1-*.html 2>/dev/null | tail -n +13 | xargs rm -f 2>/dev/null
ls -t "${REPORT_DIR}"/cis-l1-*.xml  2>/dev/null | tail -n +13 | xargs rm -f 2>/dev/null

# Tilføj til crontab — kør hver søndag kl. 03:00
sudo crontab -e
# Tilføj denne linje:
0 3 * * 0 /usr/local/bin/weekly-cis-scan.sh

CIS-compliance under installation (Kickstart)

Den mest effektive tilgang er at hærde servere allerede under installationen. Hvorfor bruge tid på remediation bagefter, hvis du kan få det rigtige fra starten? RHEL understøtter OpenSCAP-integration direkte i Kickstart-filer:

# Tilføj i din Kickstart-fil (.ks)
%addon org_fedora_oscap
  content-type = scap-security-guide
  profile = xccdf_org.ssgproject.content_profile_cis_server_l1
%end

Det sikrer, at serveren er CIS Level 1-compliant fra første boot. Det reducerer drastisk mængden af efterfølgende remediation og giver et solidt udgangspunkt for yderligere hærdning.

Integration i CI/CD og DevSecOps-pipelines

For moderne infrastruktur-teams hører compliance-scanning naturligt hjemme i DevSecOps-pipelinen. Lad os se på et konkret eksempel.

Eksempel: GitLab CI-pipeline

# .gitlab-ci.yml
stages:
  - provision
  - compliance-scan
  - remediate
  - verify

compliance-scan:
  stage: compliance-scan
  script:
    - oscap xccdf eval
        --profile xccdf_org.ssgproject.content_profile_cis_server_l1
        --results results.xml
        --report report.html
        /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml || true
    - oscap xccdf generate fix
        --fix-type ansible
        --output remediation.yml
        results.xml
  artifacts:
    paths:
      - report.html
      - remediation.yml
    expire_in: 30 days

remediate:
  stage: remediate
  script:
    - ansible-playbook -i localhost, -c local --check --diff remediation.yml
  when: manual
  allow_failure: true

Bemærk || true i scan-trinnet. OpenSCAP returnerer en exit-kode, der ikke er nul, hvis der er fejlede regler — hvilket næsten altid er tilfældet. Uden || true ville pipelinen fejle, selvom scanningen kørte fint.

Container-image scanning med oscap-im

Det nyeste værktøj i OpenSCAP-familien, oscap-im, giver mulighed for at hærde bootbare container-images direkte i Containerfiles. Det er stadig relativt nyt, men det er værd at holde øje med:

# Containerfile med OpenSCAP-hærdning
FROM registry.redhat.io/rhel9/rhel-bootc:latest

RUN dnf install -y openscap-scanner scap-security-guide && \
    oscap xccdf eval --remediate \
      --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
      /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml || true && \
    dnf clean all

Bedste praksis for CIS-compliance i produktion

Baseret på erfaringer fra virkelige produktionsmiljøer (og en del fejltagelser undervejs) er her de vigtigste principper:

• Start med Level 1: Etabler en solid baseline, før du overvejer Level 2. De fleste produktionsmiljøer opnår tilstrækkelig sikkerhed med Level 1 alene.
• Etabler en baseline først: Kør scanningen én gang for at forstå dit udgangspunkt, før du aktiverer automatiseret remediation. Det giver et klart billede af, hvor du står.
• Dokumenter dine undtagelser: Vedligehold en YAML- eller JSON-fil med bevidste afvigelser og begrundelser. Det er guld værd under revisioner — og dine fremtidige kolleger vil takke dig.
• Scan i batches: I store miljøer bør du bruge Ansibles serial-keyword til at scanne i grupper af 20-50 servere ad gangen. At scanne alt på én gang er en opskrift på problemer.
• Versionér dit SCAP-indhold: SSG opdateres løbende. Pin en version, så dine resultater er konsistente på tværs af scanningscykler.
• Automatisér, men gennemgå: Automatiseret remediation er kraftfuldt, men bør aldrig køres blindt i produktion. Brug altid check-mode først.
• Centraliser rapporter: Send scanningsresultater til et centralt system (ELK, Splunk, Wazuh) for at spore compliance over tid på tværs af hele serverflåden.
• Hærd ved installation: Brug Kickstart med OpenSCAP-integration, så servere er compliant fra dag ét. Det sparer overraskende meget tid.

Ofte stillede spørgsmål

Hvad er forskellen på OpenSCAP og Tripwire?

Tripwire er primært et file integrity monitoring-værktøj, der scanner for ændringer i filer, men uden at tilbyde automatiseret udbedring. OpenSCAP er et komplet compliance-framework, der både scanner, rapporterer og kan generere Bash-scripts og Ansible-playbooks til automatiseret remediation. OpenSCAP understøtter også flere standarder (CIS, STIG, PCI-DSS), mens Tripwire typisk fokuserer på én benchmark ad gangen.

Kan OpenSCAP-remediation fortrydes?

Kort svar: nej. Der findes i øjeblikket ingen pålidelig metode til automatisk at fortryde ændringer foretaget af OpenSCAP-remediationsscripts. Bash-scripts og Ansible-playbooks ændrer systemkonfigurationen permanent. Derfor er det afgørende at teste i et ikke-produktionsmiljø først og tage snapshots eller backups inden remediation. Det er ikke bare god praksis — det er nødvendigt.

Er det nødvendigt at opnå 100 % CIS-compliance?

Nej, og det er vigtigt at forstå. Det er helt normalt og acceptabelt, at en server ikke rammer 100 % compliance. Nogle kontroller vil altid være bevidste undtagelser i dit specifikke miljø. De fleste organisationer sigter efter 90 % eller derover og dokumenterer de resterende afvigelser med kompenserende kontroller. Det vigtigste er, at afvigelserne er bevidste, dokumenterede og godkendte af de relevante stakeholders.

Kan automatiseret scanning dække alle CIS-krav?

Ikke alle. Visse CIS-benchmarks kræver eksplicit manuelle vurderinger — for eksempel kontroller relateret til fysisk sikkerhed, organisatoriske politikker eller netværksarkitektur. OpenSCAP markerer disse som "notchecked", og de skal håndteres separat i din compliance-proces. Det er en begrænsning, man skal være opmærksom på.

Hvilke Linux-distributioner understøtter OpenSCAP med CIS-profiler?

OpenSCAP og SCAP Security Guide understøtter i 2026 CIS-profiler for RHEL 8/9/10, Ubuntu 22.04/24.04, AlmaLinux 9, Rocky Linux 9, SUSE Linux Enterprise 15, Oracle Linux 8/9 og Fedora. Hver distribution har sine egne datastream-filer og profiler, der er tilpasset operativsystemets specifikke konfiguration. Så uanset hvilken distro du kører, er der sandsynligvis en profil klar til dig.