Declaratieve Infrastructuur als Compliance Documentatie: Talos, NixOS en Audit-Ready Systemen

Compliance audits zijn pijnlijk. Iedereen die ISO 27001 certificering heeft meegemaakt kent het ritueel: weken documentatie verzamelen, screenshots van configuraties, bewijs van change management processen, bewijzen dat wat je zegt te doen ook daadwerkelijk is wat je doet.

Maar hier is iets wat ik heb gerealiseerd na jaren declaratieve infrastructuur draaien: systemen zoals Talos en NixOS maken infrastructuur niet alleen beter — ze maken compliance dramatisch makkelijker. Dezelfde eigenschappen die deze systemen betrouwbaar maken (immutability, reproduceerbaarheid, auditeerbaarheid) zijn precies wat auditors willen zien.

Laat me je tonen hoe declaratieve infrastructuur compliance documentatie wordt.

Het Compliance Probleem

De meeste compliance frameworks — ISO 27001, SOC 2, NIS2, PCI-DSS — stellen variaties van dezelfde vragen:

Wat is je systeemconfiguratie? (Asset management, configuration management)
Hoe controleer je wijzigingen? (Change management, access control)
Kun je het bewijzen? (Audit trails, bewijs)
Is het consistent? (Geen drift, geen ongedocumenteerde wijzigingen)

Traditionele infrastructuur beantwoordt deze vragen met… documentatie. Word documenten die beschrijven wat geconfigureerd zou moeten zijn. Screenshots die bewijzen dat het zo geconfigureerd was op een specifieke datum. Change tickets die refereren naar vage “server updates.”

Het probleem? Documentatie drijft weg van de realiteit. Dat Word document zegt dat servers automatische updates hebben, maar verifieert iemand dat het zes maanden later nog steeds waar is?

Declaratieve Systemen als Source of Truth

Met Talos of NixOS is je configuratie je documentatie. Er is geen kloof tussen “wat we zeggen” en “wat we doen” omdat het systeem de gedeclareerde staat afdwingt.

Talos Voorbeeld

# Dit is geen documentatie over het systeem.
# Dit IS het systeem.
machine:
  type: controlplane
  network:
    hostname: prod-control-01
  install:
    disk: /dev/sda
    image: ghcr.io/siderolabs/installer:v1.6.0
  sysctls:
    net.ipv4.ip_forward: "1"
  kubelet:
    extraArgs:
      rotate-server-certificates: "true"
cluster:
  clusterName: production
  apiServer:
    admissionControl:
      - name: PodSecurity
        configuration:
          defaults:
            enforce: "restricted"

Als een auditor vraagt “Hoe zijn je Kubernetes nodes geconfigureerd?”, geef je ze dit bestand. Het is geen benadering — het is de exacte, huidige, afgedwongen configuratie.

NixOS Voorbeeld

{
  # Security hardening - dit is zowel config ALS documentatie
  security.sudo.wheelNeedsPassword = true;
  security.auditd.enable = true;
  security.audit.rules = [
    "-w /etc/passwd -p wa -k identity"
    "-w /etc/group -p wa -k identity"
  ];

  # Firewall configuratie
  networking.firewall = {
    enable = true;
    allowedTCPPorts = [ 22 443 6443 ];
    logRefusedConnections = true;
  };

  # Automatische security updates
  system.autoUpgrade = {
    enable = true;
    allowReboot = false;
    dates = "04:00";
  };
}

Elke security control is gedefinieerd in code. De auditor kan precies zien wat geconfigureerd is, en ze weten dat het afgedwongen wordt omdat NixOS geen systeem boot dat niet matcht met deze config.

Mapping naar Compliance Controls

Laat me tonen hoe declaratieve configs mappen naar specifieke compliance requirements:

ISO 27001: A.12.1.2 - Change Management

Requirement: Wijzigingen aan systemen moeten gecontroleerd worden.

Traditionele aanpak: Change tickets, approval workflows, handmatige documentatie.

Declaratieve aanpak:

Alle wijzigingen zijn Git commits
Pull requests vereisen review
Merge naar main triggert deployment
Git history IS het change log

# Je change management bewijs
git log --oneline --since="2025-01-01" -- infrastructure/

2d8d00e Add NixOS vs Talos comparison
e49f5bd Add Talos Linux blog post
defb991 Switch image generation to DALL-E
...

Elke wijziging heeft: wie het maakte, wanneer, wat veranderde, wie het goedkeurde (PR reviewers), en waarom (commit message). Dit is beter bewijs dan welk ticketsysteem ook.

ISO 27001: A.12.6.1 - Management of Technical Vulnerabilities

Requirement: Informatie over technische kwetsbaarheden moet worden verkregen en passende maatregelen genomen.

Declaratieve aanpak met Talos:

machine:
  install:
    image: ghcr.io/siderolabs/installer:v1.7.0  # Specifieke versie

Exacte OS versie staat in Git
Updaten betekent versie wijzigen en deployen
Je kunt bewijzen welke versie op elk moment draaide
Rollback is triviaal als een kwetsbaarheid gevonden wordt in een nieuwe versie

NIS2: Artikel 21 - Cybersecurity Risk Management

Requirement: Passende technische en organisatorische maatregelen om risico’s te beheren.

Declaratief bewijs:

{
  # Netwerk segmentatie
  networking.vlans = {
    management = { id = 10; interface = "eth0"; };
    production = { id = 20; interface = "eth0"; };
  };

  # Encryptie at rest
  boot.initrd.luks.devices."encrypted".device = "/dev/sda2";

  # Access control
  services.openssh = {
    enable = true;
    settings = {
      PermitRootLogin = "no";
      PasswordAuthentication = false;
    };
  };
}

Elke control is zichtbaar, auditeerbaar en afgedwongen.

SOC 2: CC6.1 - Logical Access Controls

Requirement: De entiteit implementeert logical access security software, infrastructuur en architecturen.

Talos aanpak (radicaal maar effectief):

Geen SSH toegang überhaupt
Alle management via geauthenticeerde API
mTLS voor alle API communicatie
Role-based access via Kubernetes RBAC

# Talos machine config
machine:
  features:
    rbac: true  # Kubernetes RBAC enabled
  # Geen SSH configuratie omdat SSH niet bestaat

De auditor kan verifiëren: er is letterlijk geen SSH daemon. Access control wordt afgedwongen door architectuur, niet door beleid.

Compliance Rapporten Genereren

Hier wordt het interessant. Omdat alles in code staat, kun je automatisch compliance documentatie genereren.

Configuration Drift Report

#!/bin/bash
# Voor Talos: vergelijk gedeclareerd vs actueel

for node in $(talosctl get members -o json | jq -r '.[] | .hostname'); do
  echo "=== $node ==="
  talosctl get machineconfig -n $node -o yaml > /tmp/actual.yaml
  diff infrastructure/talos/$node.yaml /tmp/actual.yaml
done

Als dit script geen output produceert, heb je bewijs van nul configuration drift.

NixOS System Closure

# Genereer complete lijst van alle software en versies
nix-store -q --requisites /run/current-system | \
  xargs -I {} nix-store -q --binding name {} 2>/dev/null | \
  sort -u > system-inventory.txt

Dit produceert een complete software inventory — elk pakket, elke library, elke versie. Auditors houden hiervan.

Git-Based Audit Trail

# Genereer wijzigingsrapport voor auditperiode
git log --pretty=format:"%h|%an|%ad|%s" \
  --date=short \
  --since="2025-01-01" \
  --until="2025-12-31" \
  -- infrastructure/ > annual-changes.csv

Importeer in Excel, geef aan auditor. Klaar.

Continuous Compliance

De echte kracht is niet alleen audits halen — het is continue compliance. Met declaratieve systemen en GitOps:

# ArgoCD Application voor infrastructuur
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: infrastructure
spec:
  source:
    repoURL: https://github.com/company/infrastructure
    path: kubernetes/
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true  # Automatisch drift fixen

Als iemand handmatig iets wijzigt, reverteert ArgoCD het. Het systeem dwingt continu de gedeclareerde staat af. Je bent niet compliant tijdens audit — je bent altijd compliant.

Praktische Tips voor Compliance-Ready Infrastructuur

1. Gebruik Betekenisvolle Commit Messages

# Slecht
git commit -m "Update config"

# Goed
git commit -m "Enable audit logging per ISO 27001 A.12.4.1

- Added auditd configuration for file access monitoring
- Configured log retention for 90 days
- Addresses finding from Q3 security review

Ticket: SEC-1234"

Je Git history wordt compliance bewijs. Behandel het zo.

2. Tag Compliance-Gerelateerde Configs

{
  # ISO 27001 A.12.4.1 - Event Logging
  security.auditd.enable = true;

  # ISO 27001 A.13.1.1 - Network Controls
  networking.firewall.enable = true;

  # NIS2 Art.21(2)(d) - Supply Chain Security
  nix.settings.require-sigs = true;
}

Comments die config linken aan specifieke controls maken audits triviaal.

3. Versioneer Alles

# Talos machine config
machine:
  install:
    image: ghcr.io/siderolabs/installer:v1.6.0  # Niet :latest

Auditors willen exact weten welke versie draaide op een specifieke datum. Gepinde versies + Git history = complete audit trail.

4. Automatiseer Evidence Collection

#!/bin/bash
# Kwartaal compliance rapport generator

REPORT_DIR="compliance-reports/$(date +%Y-Q%q)"
mkdir -p $REPORT_DIR

# Systeem inventory
nix-store -q --requisites /run/current-system > $REPORT_DIR/inventory.txt

# Configuratie snapshots
cp -r /etc/nixos $REPORT_DIR/nixos-config/

# Wijzigingslog
git log --since="3 months ago" -- infrastructure/ > $REPORT_DIR/changes.txt

# Drift check
./scripts/check-drift.sh > $REPORT_DIR/drift-report.txt

echo "Rapport gegenereerd in $REPORT_DIR"

Draai elk kwartaal, archiveer, presenteer aan auditors.

Het Grotere Plaatje

Declaratieve infrastructuur maakt compliance niet alleen makkelijker — het maakt compliance echt.

Traditionele compliance vervalt vaak in checkbox-oefeningen. Documenten zeggen één ding, realiteit zegt iets anders, en iedereen doet alsof tijdens audit seizoen. Dit is theater, geen security.

Met Talos, NixOS en GitOps wordt compliance een bijproduct van goede engineering. Het systeem is veilig omdat het immutable is. Wijzigingen worden getrackt omdat ze door Git gaan. Drift is onmogelijk omdat het systeem de gedeclareerde staat afdwingt.

Je doet geen extra werk voor compliance — je doet infrastructuur correct, en compliance bewijs valt er vanzelf uit.

De beste compliance houding is infrastructuur die niet non-compliant kan zijn. Declaratieve systemen brengen je daar.

Het Compliance Probleem#

Declaratieve Systemen als Source of Truth#

Talos Voorbeeld#

NixOS Voorbeeld#

Mapping naar Compliance Controls#

ISO 27001: A.12.1.2 - Change Management#

ISO 27001: A.12.6.1 - Management of Technical Vulnerabilities#

NIS2: Artikel 21 - Cybersecurity Risk Management#

SOC 2: CC6.1 - Logical Access Controls#

Compliance Rapporten Genereren#

Configuration Drift Report#

NixOS System Closure#

Git-Based Audit Trail#

Continuous Compliance#

Praktische Tips voor Compliance-Ready Infrastructuur#

1. Gebruik Betekenisvolle Commit Messages#

2. Tag Compliance-Gerelateerde Configs#

3. Versioneer Alles#

4. Automatiseer Evidence Collection#

Het Grotere Plaatje#