Policy as Code: Compliance-Anforderungen mit Polycrate automatisieren

TL;DR

• Manuelles Compliance-Checking mit Excel-Listen ist langsam, fehleranfällig und kaum nachweisbar reproduzierbar – mit Policy as Code beschreiben Sie Ihre Anforderungen einmal und lassen sie dann automatisch prüfen.
• Mit Polycrate kapseln Sie Ansible vollständig im Container: keine lokale Installation, keine Python-Version-Konflikte, gleiche Tooling-Version für alle Beteiligten – ideal für wiederholbare Compliance-Prüfungen.
• Ein eigener „Compliance-Block“ trennt Prüfen (check) und Korrigieren (remediate), generiert Audit-Reports als JSON/CSV und legt sie strukturiert im Workspace ab – inklusive Git-Historie als Audit-Trail.
• NIS‑2 (Anwendung der Maßnahmen ab dem 18.10.2024) und DSGVO (seit dem 25.05.2018 in Kraft) fordern nachweisbare technische und organisatorische Maßnahmen. Mit Policy as Code können Sie konkrete Controls (z. B. CIS Benchmarks) automatisiert prüfen.
• ayedo unterstützt Sie mit Open-Source-Tooling, Platform Engineering und speziell zugeschnittenen Workshops, um Compliance-Automatisierung sicher und verständlich in Ihre Organisation zu bringen.

Warum manuelles Compliance-Checking an Grenzen stößt

Viele Compliance-Teams arbeiten noch mit Excel-Checklisten oder Word-Dokumenten:

• Spalte A: Anforderung (z. B. „SSH Root-Login deaktivieren“)
• Spalte B: Status („OK“ / „nicht OK“)
• Spalte C: Kommentar („am 12.02.2026 geprüft von …“)

Das funktioniert, solange Sie wenige Systeme und seltene Audits haben. Spätestens bei:

• hunderten Servern (Linux und Windows),
• wiederkehrenden Audits (intern, extern, Kunden),
• neuen Vorgaben durch NIS‑2 oder strengere interne Policies

wird das Modell brüchig:

• Zeitaufwändig: Jede Prüfung ist Handarbeit.
• Fehleranfällig: Tippfehler, Copy & Paste, vergessene Schritte.
• Nicht reproduzierbar: Zwei Personen prüfen dasselbe System – Ergebnis kann abweichen.
• Schwach im Audit: „Wie genau haben Sie das geprüft?“ lässt sich oft nur mündlich beantworten.

Policy as Code dreht das um: Die Checkliste wird zu ausführbarem Code. Die Frage lautet dann nicht mehr „Wer hat was wie geprüft?“, sondern:

• „Welche Version der Prüflogik lief wann gegen welche Systeme?“

Genau hier setzt Polycrate mit Ansible an – ohne dass Sie Entwickler sein müssen.

Policy as Code: Compliance als wiederholbarer Prozess

Policy as Code bedeutet: Compliance-Anforderungen werden in maschinenlesbarer Form beschrieben. Für unsere Zwecke:

• YAML-Dateien als Playbooks (Ansible),
• klar definierte Tasks pro Anforderung,
• automatisierte Ausführung gegen definierte Systeme.

Beispiel: Ein CIS-Benchmark fordert, dass /etc/passwd nur lesbar, aber nicht schreibbar für „Others“ ist. Statt in Excel „OK“ anzukreuzen, definieren Sie einen Task:

• Prüfe Dateirechte
• Vergleiche mit Soll-Wert
• Melde „compliant“ oder „non-compliant“

Der Vorteil:

• Reproduzierbar: Die gleiche Logik läuft jede Woche, jeden Monat, in jedem Audit.
• Nachvollziehbar: Änderungen an der Policy sind als Codeänderung sichtbar.
• Automatisierbar: Hunderte Hosts sind nicht mehr viel teurer als ein Host.

Mit Polycrate koppeln Sie diese Playbooks an eine strukturierte Umgebung (Workspace), Container-basiertes Tooling und Git – das macht Policy as Code für Compliance-Verantwortliche beherrschbar.

Polycrate als Fundament für automatisierte Compliance

Was unterscheidet Polycrate von „plain“ Ansible aus Compliance-Sicht?

Keine Abhängigkeiten auf Laptops

Mit klassischem Ansible müssen Sie oft:

• Python in der richtigen Version installieren,
• Ansible-Versionen im Team synchron halten,
• zusätzliche Tools (kubectl, Helm, Python-Bibliotheken) manuell pflegen.

Das „Dependency-Problem“ führt zu:

• unterschiedlichen Ergebnissen je nach Laptop,
• Sicherheitsrisiken durch veraltete Pakete.

Mit Polycrate:

• Läuft Ansible immer in einem Container.
• Bringt eine komplette Toolchain mit (Ansible, Python, ggf. kubectl/Helm).
• Ist die Umgebung auf allen Arbeitsplätzen identisch.

Sie starten eine Compliance-Prüfung mit einem Befehl, ohne sich um die lokale Technik zu kümmern. Details zur Ansible-Integration finden Sie in der Dokumentation zu Ansible und Polycrate.

Guardrails statt Playbook-Wildwuchs

Polycrate zwingt Ihre Automatisierung in eine klare Struktur:

• Workspace (z. B. acme-corp-automation)
• Blöcke (z. B. cis-linux-baseline)
• Actions pro Block (z. B. check, remediate)

Das verhindert, dass überall lose Playbooks liegen, die niemand mehr zuordnen kann. Mehr dazu in den Best Practices.

Verschlüsselter Workspace für sensible Daten

Compliance-Prüfungen arbeiten oft mit:

• Server-Adressen,
• Service-Accounts,
• Konfigurationsdetails.

Der Polycrate-Workspace kann mit age verschlüsselt werden – ohne zusätzliches Tool wie Vault. Damit liegen sensible Informationen geschützt im Repository. Die Details dazu stehen in der Dokumentation zur Workspace-Verschlüsselung.

Git als Audit-Trail

Ein zentraler Baustein für Audits: jede Änderung, jede Prüfung, jeder Report ist in Git nachvollziehbar. Polycrate arbeitet ideal mit Git zusammen, etwa:

• Playbooks und Block-Konfigurationen im Repository,
• generierte Reports im artifacts/-Verzeichnis,
• Commits zum Zeitpunkt der Prüfung.

Die Git-Integration von Polycrate ist in der Doku zu Git-Workflows beschrieben.

Ein Compliance-Block für CIS-Checks auf Linux-Servern

Im Folgenden bauen wir einen einfachen Block, der zwei Dinge tut:

• check: CIS-ähnliche Checks auf Linux-Servern ausführen.
• remediate: einige Abweichungen automatisch korrigieren.

Zielgruppe: Linux-Server (z. B. Ubuntu 22.04) in einer Domain acme-corp.com.

Workspace und Inventory anlegen

Im Workspace-Root legen Sie die workspace.poly an:

name: acme-corp-automation
organization: acme

blocks:
  - name: cis-linux-baseline
    from: registry.acme-corp.com/acme/compliance/cis-linux-baseline:0.1.0
    config:
      report_format: "json"

Der Block kommt per from: aus einer OCI-Registry (hier fiktiv registry.acme-corp.com/...; öffentlich z. B. cargo.ayedo.cloud oder PolyHub). Die Version ist im from: gepinnt (:0.1.0). Ausgabepfade für Reports gehören nicht in workspace.poly/block.poly, sondern werden im Playbook aus block.artifacts.path abgeleitet – siehe Artefakte.

Das YAML-Inventory liegt ebenfalls im Workspace-Root als inventory.yml:

all:
  hosts:
    server01.acme-corp.com:
      ansible_user: ubuntu
    server02.acme-corp.com:
      ansible_user: ubuntu

Polycrate setzt ANSIBLE_INVENTORY automatisch auf dieses File. Die Playbooks können einfach hosts: all verwenden – sie laufen im Container, greifen aber per SSH auf Ihre Server zu.

Block für Compliance-Prüfung definieren

Nach polycrate blocks pull liegt der Block unter blocks/registry.acme-corp.com/acme/compliance/cis-linux-baseline/. Dort legen Sie die block.poly an (name = vollständiger Registry-Pfad ohne Tag):

name: registry.acme-corp.com/acme/compliance/cis-linux-baseline
version: 0.1.0
kind: generic

config:
  report_format: "json"

actions:
  - name: check
    playbook: check.yml
  - name: remediate
    playbook: remediate.yml

Wichtige Punkte:

• version pinnt den Block-Stand – wichtig für Nachvollziehbarkeit im Audit.
• In workspace.poly können Sie z. B. report_format pro Instanz überschreiben – nur literale YAML-Werte, keine Jinja2-Ausdrücke. In workspace.poly und block.poly gibt es keine Template-Substitution (kein Jinja2); dynamische Pfade setzen Sie in Ansible, z. B. über block.artifacts.path. Details: Konfiguration – Einschränkungen und Blöcke.
• Zwei Actions trennen klare Verantwortlichkeiten: Prüfen vs. Korrigieren.

Ansible-Playbook: CIS-Checks (check-action)

Nun die check.yml im gleichen Verzeichnis:

- name: CIS Linux Baseline Check
  hosts: all
  become: true
  gather_facts: false

  vars:
    cis_results: []
    report_dir: "{{ block.artifacts.path }}/reports"

  tasks:
    - name: Check 1 – /etc/passwd permissions
      ansible.builtin.stat:
        path: /etc/passwd
      register: passwd_stat

    - name: Evaluate 1 – /etc/passwd should be 0644
      ansible.builtin.assert:
        that:
          - passwd_stat.stat.mode == "0644"
        fail_msg: "/etc/passwd permissions are not 0644"
        success_msg: "/etc/passwd permissions are 0644"
      register: passwd_check

    - name: Check 2 – SSH root login disabled
      ansible.builtin.command: "sshd -T"
      register: sshd_config
      changed_when: false

    - name: Evaluate 2 – PermitRootLogin should be no
      ansible.builtin.assert:
        that:
          - "'permitrootlogin no' in sshd_config.stdout_lines"
        fail_msg: "SSH root login is not disabled"
        success_msg: "SSH root login is disabled"
      register: ssh_root_check

    - name: Build CIS result structure
      ansible.builtin.set_fact:
        cis_results: >-
          {{
            cis_results + [
              {
                "control": "CIS-5.4.1",
                "description": "/etc/passwd permissions 0644",
                "passed": passwd_check is succeeded
              },
              {
                "control": "CIS-5.2.8",
                "description": "SSH root login disabled",
                "passed": ssh_root_check is succeeded
              }
            ]
          }}

    - name: Ensure report directory exists
      ansible.builtin.file:
        path: "{{ report_dir }}"
        state: directory
        mode: "0750"

    - name: Write JSON report
      ansible.builtin.copy:
        dest: "{{ report_dir }}/cis-linux-{{ inventory_hostname }}.json"
        content: "{{ cis_results | to_nice_json }}"
        mode: "0640"

Was hier passiert:

• ansible.builtin.stat prüft Dateirechte.
• ansible.builtin.command liest die aktuelle SSHD-Konfiguration.
• ansible.builtin.assert bewertet, ob der Soll-Zustand erfüllt ist.
• ansible.builtin.file legt das Report-Verzeichnis unter {{ block.artifacts.path }}/reports an (nicht als festen Pfad in block.poly – siehe Artefakte).
• ansible.builtin.copy schreibt einen JSON-Report je Host in dieses Verzeichnis.

Die Module sind bewusst einfach gehalten – Compliance-Verantwortliche können den Text in description und fail_msg leicht nachvollziehen.

Ansible-Playbook: Remediation (remediate-action)

Jetzt die remediate.yml:

- name: CIS Linux Baseline Remediation
  hosts: all
  become: true
  gather_facts: false

  tasks:
    - name: Fix 1 – Set /etc/passwd permissions to 0644
      ansible.builtin.file:
        path: /etc/passwd
        mode: "0644"

    - name: Fix 2 – Disable SSH root login in sshd_config
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        create: no
        backup: yes

    - name: Reload SSH service
      ansible.builtin.command: "systemctl reload sshd"
      changed_when: true

Dieses Playbook nutzt:

• ansible.builtin.file, um Dateirechte zu setzen.
• ansible.builtin.lineinfile (zusätzlich zum verlangten Modulsatz), um die SSH-Konfiguration anzupassen.
• ansible.builtin.command, um den Dienst neu zu laden.

Wichtig: Idempotenz. Wenn ein System bereits compliant ist, ändern sich Dateien nicht unnötig – ein Kernprinzip von Ansible.

Polycrate-Befehle ausführen

Aus dem Workspace-Root können Sie die Aktionen direkt starten:

polycrate run cis-linux-baseline check

Nach Abschluss finden Sie für jeden Host einen JSON-Report unter {{ block.artifacts.path }}/reports/ (typisch artifacts/blocks/<registry-pfad>/reports/).

Wenn Sie Abweichungen korrigieren möchten:

polycrate run cis-linux-baseline remediate

Und anschließend erneut prüfen:

polycrate run cis-linux-baseline check

Mit „plain“ Ansible müssten Sie:

• Ansible lokal installieren,
• Inventories und Pfade manuell setzen,
• Playbooks mit korrekten Parametern aufrufen.

Mit Polycrate reduziert sich das auf klare, nicht-technische Befehle – gut geeignet, um z. B. einem ISO eine eigene „Compliance-Konsole“ an die Hand zu geben.

Audit-Report und Git als Nachweis

Typischer Ablauf für eine dokumentierte Prüfung:

# Workspace ggf. entschlüsseln
polycrate workspace decrypt

# Compliance-Check ausführen
polycrate run cis-linux-baseline check

# Ergebnisse einsehen (Pfad = Block-Artefakte + /reports)
ls artifacts/blocks/registry.acme-corp.com/acme/compliance/cis-linux-baseline/reports/
cat artifacts/blocks/registry.acme-corp.com/acme/compliance/cis-linux-baseline/reports/cis-linux-server01.acme-corp.com.json

# Änderungen ins Git-Repository übernehmen
git add artifacts/blocks/
git commit -m "CIS Linux baseline check 2026-03-25"
git push

Im Audit können Sie dann konkret zeigen:

• welcher Block (inkl. version) verwendet wurde,
• welche Hosts geprüft wurden (Inventory),
• welche Ergebnisse dabei herauskamen (Reports),
• und wann das Ganze ausgeführt wurde (Commit-Zeitpunkt).

Policy as Code im Kontext von NIS‑2 und DSGVO

NIS‑2 (Richtlinie (EU) 2022/2555) ist am 16.01.2023 in Kraft getreten; die Mitgliedstaaten müssen die Vorgaben bis zum 17.10.2024 umsetzen. Die Maßnahmen sind ab dem 18.10.2024 anzuwenden. Die DSGVO gilt bereits seit dem 25.05.2018.

Beide Regime fordern, stark vereinfacht:

• Geeignete technische und organisatorische Maßnahmen,
• regelmäßige Überprüfung und Evaluierung dieser Maßnahmen,
• Nachweisbarkeit gegenüber Aufsichtsbehörden und Prüfern.

Mit Policy as Code können Sie z. B. automatisiert prüfen:

• ob Protokollierung und Logging-Dienste aktiv sind (CIS-Controls),
• ob unnötige Dienste deaktiviert sind,
• ob SSH- und Remote-Zugänge gehärtet sind,
• ob Systemdateien und Konfigurationen korrekte Rechte haben,
• ob Verschlüsselung für bestimmte Pfade/Dateien aktiv ist (je nach Modulwahl).

Diese technischen Controls sind nicht nur „nice to have“ – sie stützen:

• NIS‑2-Anforderungen an Incident-Prevention und Netzwerksicherheit,
• DSGVO-Artikel zu Integrität und Vertraulichkeit sowie Sicherheit der Verarbeitung.

Polycrate hilft hier, weil:

• die Prüfungen als Code im Repository liegen,
• die ausführende Umgebung (Container) reproduzierbar ist,
• sensible Daten im Workspace verschlüsselt werden können,
• Ergebnisse langfristig in Git archiviert werden.

Für komplexere Umgebungen (z. B. gemischte Linux/Windows-Landschaften oder OT/IoT-Komponenten) lassen sich weitere Blöcke bauen oder aus der PolyHub bzw. eigenen Registries beziehen und versioniert teilen („Sharable Automation“).

Häufige Fragen

Muss ich programmieren können, um Policy as Code mit Polycrate zu nutzen?

Nein. Sie sollten:

• grundlegende YAML-Strukturen lesen können,
• verstehen, was ein „Task“ oder eine „Action“ konzeptionell tut,
• die beschriebenen Controls fachlich einordnen können.

Die eigentliche Technik (Container, Ansible, Python) kapselt Polycrate. Viele Compliance-Teams arbeiten so: Ein technisch versierter Kollege oder ein externer Partner baut die Blocks, das Compliance-Team führt sie mit einfachen Befehlen aus und interpretiert die Berichte.

Wie passt Policy as Code in unsere bestehende Governance und Dokumentation?

Policy as Code ergänzt Ihre bestehenden Richtlinien:

• Die „große“ IT-Sicherheitsrichtlinie bleibt wie sie ist.
• Konkrete technische Controls bekommen eine maschinenlesbare Entsprechung (Playbooks).
• In Ihren Richtlinien verweisen Sie auf die jeweilige Block-Version und den Ausführungsrhythmus.

Über Git-Historie und Polycrate-Workspaces entsteht ein konsistenter Nachweis, der sehr gut in bestehende GRC-Tools oder Auditdokumentationen integriert werden kann.

Ist das nicht zu technisch für ein Compliance-Team?

Die Erfahrung zeigt: Wenn die ersten zwei, drei Blöcke stehen, sinkt die Einstiegshürde drastisch. Wichtig ist eine klare Rollenverteilung:

• Technik (z. B. ein Platform Engineering-Team oder ayedo) kümmert sich um Blocks und Infrastruktur.
• Compliance definiert Anforderungen, Szenarien und Bewertungslogik.
• Gemeinsam wird entschieden, welche Checks auch automatisch „remediate“ dürfen und wo weiterhin manuelle Freigaben nötig sind.

Polycrate unterstützt diese Trennung durch klare Actions und eine einfache CLI. Zusätzlich bietet die Polycrate API höherwertige Schnittstellen: Workspaces, Blöcke und Actions lassen sich dort ansprechen und in andere Tools oder Self-Service-Frontends einbinden – sinnvoll, wenn nicht alle Stakeholder mit der Kommandozeile arbeiten.

Weitere Fragen? Siehe unsere FAQ

Compliance in der Praxis

Mit dem gezeigten Beispiel haben Sie gesehen:

• wie Sie eine manuelle CIS-Checkliste in ein Ansible-Playbook übersetzen,
• wie Polycrate daraus einen strukturierten Compliance-Block mit check- und remediate-Actions macht,
• wie Reports als JSON-Dateien unter block.artifacts.path landen und per Git zu einem belastbaren Audit-Trail werden,
• und wie sich diese Arbeitsweise in den Kontext von NIS‑2 und DSGVO einfügt.

Für viele Organisationen ist der entscheidende Schritt nicht das einzelne Playbook, sondern der Aufbau einer wiederholbaren Plattform für Compliance-Automatisierung:

• Containerisierte Toolchain statt individueller Admin-Laptops,
• verschlüsselte Workspaces für sensible Daten,
• klar definierte Blöcke pro Themengebiet (z. B. „Linux CIS“, „Windows Hardening“, „Datenbank-Security“),
• saubere Git-Prozesse und nachvollziehbare Historie.

Genau hier setzt ayedo an: Wir verbinden Open-Source-Tools wie Polycrate mit erprobten Platform Engineering-Ansätzen und unterstützen Sie dabei, Policy as Code so einzuführen, dass sie für Compliance-Teams verständlich, für IT-Abteilungen handhabbar und für Auditoren belastbar ist.

Wenn Sie den nächsten Schritt gehen und eine auf Ihre Umgebung zugeschnittene Lösung erarbeiten möchten, starten wir gern mit einem praxisorientierten Format – Übersicht und Buchung:

Workshops