Auditierbare Operations: SSH-Sessions und CLI-Aktivitäten mit Polycrate API

TL;DR

• Polycrate protokolliert nicht nur Action Runs (Ansible-Playbooks), sondern auch SSH-Sessions, Workspace-Syncs und CLI-Instanzen – alles zentral über die Polycrate API abrufbar.
• SSH-Session-Logging beantwortet die klassische Incident-Response-Frage: Wer hat wann per SSH auf welchen Server zugegriffen, wie lange, mit welchem Exit-Code?
• Workspace-Sync-Logs halten Git-Branch, Commit-SHA, Encryption-Status und Sync-Ergebnis fest und machen Änderungen an Automatisierung nachvollziehbar und revisionssicher.
• Über die Polycrate API lassen sich Encryption Keys für verschlüsselte Workspaces zentral verwalten – ein wichtiger Baustein für NIS‑2- und DSGVO-konforme Betriebsprozesse.
• ayedo liefert mit Polycrate, der API und begleitenden Platform-Engineering-Services einen auditierbaren Operations-Stack, der sich in bestehende Compliance- und Security-Prozesse integrieren lässt.

Warum Operations-Audit heute Chefsache ist

Sowohl NIS‑2 als auch DSGVO verschärfen den Druck auf nachvollziehbares, dokumentiertes IT-Betriebsverhalten:

• Die NIS‑2-Richtlinie (EU) 2022/2555 muss von den EU-Mitgliedstaaten bis zum 17.10.2024 in nationales Recht umgesetzt werden. Sie fordert u.a. technische und organisatorische Maßnahmen zur Protokollierung und Überwachung sicherheitsrelevanter Ereignisse.
• Die DSGVO (Datenschutz-Grundverordnung) gilt seit dem 25.05.2018 und verlangt u.a. Rechenschaftspflicht: Sie müssen nachweisen können, wer wann auf personenbezogene Daten zugegriffen oder Systeme verändert hat, die solche Daten verarbeiten.

Orientierung zu regulatorischen Rahmenbedingungen und ihrer Operationalisierung bietet die Landingpage Compliance Compass.

In Sicherheitsvorfällen taucht praktisch immer als eine der ersten Fragen auf:

Wer hat wann per SSH auf welchen Server zugegriffen?

Mit klassischem Werkzeugmix – ein bisschen Ansible, ein bisschen manuelles SSH, lokale ~/.bash_history, verstreute Syslog-Einträge – ist diese Frage oft nur mit großem Aufwand zu beantworten, manchmal gar nicht.

Polycrate setzt genau dort an: Es macht Ansible, SSH-Zugriffe und Workspace-Synchronisation auditierbar – ohne dass Ihr Team zusätzliche Agenten oder Spezialtools auf allen Servern ausrollen muss. Alles läuft über die Polycrate CLI und die Polycrate API, siehe API-Dokumentation und SSH-Integration.

Polycrate als Audit-Backbone für Ihren Betrieb

Bevor wir in die Details des Audit-Trails einsteigen, kurz zur Einordnung, was Polycrate generell bringt:

• Dependency-Problem gelöst: Ansible, Python, kubectl, Helm & Co. laufen in einem Container, den Polycrate steuert. Sie müssen lokal kein Ansible installieren, keine Python-Versionen jonglieren und haben weniger Supply-Chain-Risiken. Jeder im Team arbeitet mit derselben, reproduzierbaren Toolchain – ein Kernprinzip von gutem Platform Engineering.
• Struktur statt Playbook-Wildwuchs: Das Block-Modell gibt Ansible eine wiederverwendbare, versionierbare Struktur. Blöcke können via OCI-Registry oder PolyHub geteilt werden – inklusive aller Audit-Daten, die die API liefert.
• Workspace-Verschlüsselung: Secrets im Workspace werden mit age verschlüsselt, siehe Workspace-Verschlüsselung. Kein externer Vault nötig – ein wichtiges Detail für DSGVO- und NIS‑2-Audits.

Auf dieser Basis setzt Polycrate eine zusätzliche Schicht: einen zentralen Audit-Trail für alle Betriebsaktionen, abrufbar und integrierbar über die Polycrate API.

Über Action Runs hinaus: Was wirklich im Alltag passiert

In vielen Teams sieht der Alltag heute so aus:

• Geplante Änderungen laufen per Ansible-Playbook (oder CI-Pipeline).
• Dringende Hotfixes oder Debug-Sessions passieren „mal eben schnell“ per SSH.
• Workspaces und Inventories werden unregelmäßig per git pull aktualisiert oder per Copy/Paste verteilt.

Mit plain Ansible haben Sie bestenfalls:

• Log-Dateien auf dem Control-Host (wenn Sie Logging sauber konfiguriert haben).
• SSH-Logs auf den Zielsystemen – verteilt, unterschiedlich konfiguriert, teils rotiert oder gelöscht.
• Kein zentrales Bild, wer mit welcher Tool-Version wann welche Operation ausgeführt hat.

Polycrate schließt diese Lücken:

1. Action Runs (Ansible-Playbooks) werden zentral geloggt.
2. SSH-Sessions, die Sie über Polycrate starten, erzeugen eigene Audit-Einträge.
3. Workspace-Syncs werden mit Git-Metadaten und Encryption-Status protokolliert.
4. CLI-Instanzen melden sich bei der API – inklusive Polycrate-Version und Hostname.

So entsteht eine vollständige Operations-Historie, in der automatisierte und manuelle Eingriffe gleichwertig aufscheinen.

SSH-Session-Logging: endlich Antwort auf „Wer hat wann per SSH zugegriffen?“

SSH ist der Klassiker für Incident-Response-Fragen – und einer der größten blinden Flecken in vielen Umgebungen.

Mit Polycrate läuft eine SSH-Session typischerweise so:

polycrate ssh server01.acme-corp.com

Die Details zur SSH-Funktion finden Sie in der SSH-Dokumentation.

Wenn Sie SSH über Polycrate verwenden, passiert im Hintergrund:

• Beim Start der Session wird ein Audit-Event an die Polycrate API gesendet.
• Beim Beenden der Session wird ein weiteres Event geschickt, inkl.
  • Exit-Code
  • Dauer
  • ggf. Abbruchgrund (Timeout, Netzwerkfehler etc.)

Typischer Datensatz in der API (vereinfachtes Beispiel):

{
  "type": "ssh_session",
  "id": "c5f4411d-641a-4b0a-8ee6-291d1c725c20",
  "workspace": "acme-corp-automation",
  "user": "alice",
  "cli_instance_id": "cli-8f3891b2",
  "host": {
    "inventory_name": "server01.acme-corp.com",
    "ansible_host": "10.0.12.34",
    "hostname_reported": "srv-web-01"
  },
  "started_at": "2026-03-24T10:12:03Z",
  "ended_at": "2026-03-24T10:27:45Z",
  "duration_seconds": 942,
  "exit_code": 0
}

Damit können Sie in einem Vorfall gezielt fragen:

• Welche SSH-Sessions gab es auf server01.acme-corp.com im Zeitraum X–Y?
• Wer hat sich eingeloggt?
• Welche Workspace-Version war im Einsatz?
• Wurden parallel Ansible-Action-Runs ausgeführt?

Wichtig:
Die SSH-Verbindung selbst läuft weiterhin per SSH-Client, nicht über einen API-Tunnel. Polycrate nutzt die API nur für das Audit-Event – keine zusätzliche Agenteninstallation auf den Zielsystemen.

Im Vergleich dazu müssten Sie mit plain Ansible:

• zentrales SSH-Jump-Host-Logging aufbauen,
• Log-Rotation und -Aggregation konfigurieren,
• Benutzeridentitäten mit technischen Accounts korrelieren,
• und hätten trotzdem keinen direkten Bezug zu Workspaces und Ansible-Runs.

Mit Polycrate reicht ein konsistenter Einstiegspunkt (polycrate ssh) – der Rest passiert automatisch.

Workspace-Sync-Logging: Wer hat welches Playbook in welche Richtung gezogen?

Polycrate-Workspaces sind die Einheit, in der Sie Blöcke, Inventories und Konfiguration verwalten, siehe Workspaces-Dokumentation.

Typischer Workflow:

polycrate workspace sync

Dahinter verbirgt sich meist ein Git-Pull/Push oder ein Sync gegen ein zentrales Repository. Polycrate protokolliert dazu über die API u.a.:

• Workspace-Name
• Git-Remote-URL (pseudonymisiert/gekürzt, je nach Konfiguration)
• Git-Branch
• Commit-SHA vor und nach dem Sync
• Encryption-Status:
  • Sind Secrets im Workspace verschlüsselt?
  • Wurde ein Key-Rotation-Event erkannt?
• Ergebnis: Erfolg, Konflikt, Abbruch, Fehlermeldung

Beispiel eines API-Eintrags:

{
  "type": "workspace_sync",
  "id": "0c19e60f-9d4f-4f3b-b9fb-909cb7ab2f37",
  "workspace": "acme-corp-automation",
  "user": "bob",
  "git": {
    "branch": "main",
    "before_sha": "dc3a1f7",
    "after_sha": "a42b9e1"
  },
  "encryption": {
    "enabled": true,
    "key_id": "age1qg4...",
    "status": "ok"
  },
  "result": "success",
  "timestamp": "2026-03-24T08:02:11Z"
}

Das ist Gold wert für Compliance und Revisionssicherheit:

• Sie sehen, wann neue Playbook-Versionen im Workspace angekommen sind.
• Sie können Action Runs und SSH-Sessions mit dem verwendeten Commit verknüpfen.
• Sie können nachweisen, dass Secrets im Workspace verschlüsselt waren, als eine Änderung ausgerollt wurde.

Mit plain Ansible müssten Sie dafür externe Git-Logs, CI-Logs und manuelle Dokumentation korrelieren.

CLI Instance Tracking: Welche Polycrate-Version ist wo im Einsatz?

Eine häufig unterschätzte Frage in Audits lautet:

Welche Version der Operations-Tools ist im Einsatz – und wo?

Polycrate beantwortet das, indem jede CLI-Instanz sich regelmäßig bei der API meldet, z.B. beim Start einer Action, eines Syncs oder einer SSH-Session. Ein Datensatz enthält u.a.:

• cli_instance_id
• Polycrate-Version (cli_version)
• Betriebssystem und Architektur
• Hostname bzw. anonymisierte Host-ID
• Workspace-Bezüge

Beispiel:

{
  "type": "cli_instance",
  "id": "cli-8f3891b2",
  "user": "alice",
  "cli_version": "0.8.4",
  "os": "linux",
  "arch": "amd64",
  "hostname": "alice-laptop",
  "first_seen": "2026-03-22T09:00:00Z",
  "last_seen": "2026-03-24T10:27:45Z"
}

Damit können Sie:

• sicherstellen, dass sicherheitskritische CLI-Versionen ausgerollt sind,
• alte, verwundbare oder nicht compliant konfigurierte Versionen identifizieren,
• im Audit zeigen, dass nur freigegebene Tool-Versionen verwendet wurden.

Encryption Key Management via API: Teamweite Verschlüsselung im Griff

Polycrate verschlüsselt Workspace-Secrets mit age, siehe Workspace-Verschlüsselung. Statt jeden Workspace einzeln zu managen, können Sie über die API:

• Key-IDs und Metadaten verwalten (z.B. für Team-Schlüssel, Projekt-Schlüssel).
• Key-Rotation planen und überwachen – inklusive Audit-Einträgen, wann ein Workspace auf einen neuen Key gehoben wurde.
• Zugriffsrechte auf Encryption Keys auf API-Ebene steuern (z.B. nur bestimmte Rollen dürfen Keys erstellen oder löschen).

In NIS‑2- und DSGVO-Kontexten ist das entscheidend:

• Sie können nachweisen, dass sensible Konfiguration und Zugangsdaten im Workspace verschlüsselt gespeichert sind.
• Sie haben einen Audit-Trail darüber, wer wann Keys erzeugt, geändert oder deaktiviert hat.
• Sie reduzieren den Wildwuchs von lokal gespeicherten Schlüsselmaterialien.

Konkretes Beispiel: Ein gepatchter Server mit vollständigem Audit-Trail

Um das greifbar zu machen, schauen wir uns einen kleinen, aber vollständigen Workflow an:

• Ein Workspace acme-corp-automation
• Ein Block linux-patch, der ein Ansible-Playbook ausführt
• Ein Inventory im Workspace-Root (inventory.yml)
• Ein Admin, der vor und nach dem Patch per SSH auf den Server schaut

Workspace-Definition mit API-Konfiguration

# workspace.poly
name: acme-corp-automation
organization: acme

config:
  api_base_url: "https://polycrate-api.acme-corp.com"

blocks:
  - name: linux-patch
    from: linux-patch
    config:
      target_hosts: "all"

Weitere Details zu Workspaces finden Sie in der Workspaces-Dokumentation und zu Best Practices in den Polycrate-Best Practices.

Block-Definition für den Patch

# blocks/linux-patch/block.poly
name: linux-patch
version: 0.1.0
kind: generic

config:
  target_hosts: "all"

actions:
  - name: patch
    description: "Installiere Security-Updates auf Linux-Servern"
    type: ansible
    playbook: patch.yml

Der Block liegt lokal im Workspace (./blocks/linux-patch). In echten Setups könnten Sie diesen Block z.B. auch aus einer Registry oder von PolyHub beziehen – immer mit expliziter Version, siehe Registry-Dokumentation.

Inventory mit Remote-Hosts

# inventory.yml (Workspace-Root)
all:
  hosts:
    server01.acme-corp.com:
      ansible_host: 10.0.12.34
      ansible_user: ubuntu
    server02.acme-corp.com:
      ansible_host: 10.0.12.35
      ansible_user: ubuntu

Polycrate setzt ANSIBLE_INVENTORY automatisch auf dieses YAML-Inventory, siehe Ansible-Integration.

Wichtig: Wir verwenden nicht hosts: localhost mit connection: local, weil das nur im Polycrate-Container wirken würde.

Ansible-Playbook für den Patch

# blocks/linux-patch/patch.yml
- name: Security-Patches installieren
  hosts: "{{ block.config.target_hosts }}"
  become: true
  gather_facts: false

  tasks:
    - name: Paketlisten aktualisieren (APT)
      ansible.builtin.apt:
        update_cache: true
      when: ansible_facts.os_family == "Debian"

    - name: Security-Updates installieren (APT)
      ansible.builtin.apt:
        upgrade: dist
      when: ansible_facts.os_family == "Debian"

    - name: Alle Pakete aktualisieren (YUM/DNF)
      ansible.builtin.yum:
        name: "*"
        state: latest
      when: ansible_facts.os_family in ["RedHat", "Rocky", "AlmaLinux"]

Die Variable block.config.target_hosts kommt direkt aus der block.poly und wird von Polycrate in den Ansible-Context injiziert, siehe Actions-Dokumentation.

Polycrate-Run mit Audit

Der Patch-Lauf wird so gestartet:

polycrate run linux-patch patch

Was passiert dabei aus Audit-Sicht?

1. Die Polycrate CLI erstellt einen Action-Run-Eintrag per API:
   • Workspace, Block, Action-Name
   • Startzeit, User, CLI-Version, Inventory-Hosts
2. Ansible läuft im Container; Logs und Exit-Status werden mit dem Action-Run verknüpft.
3. Nach Ende sendet die CLI den finalen Status (Erfolg/Fehlschlag, Dauer, betroffene Hosts) an die API.

Wenn der Admin nun zusätzlich per SSH auf server01.acme-corp.com geht:

polycrate ssh server01.acme-corp.com

…entstehen zusätzliche SSH-Session-Events, die Sie später mit dem Patch-Lauf und dem Commit-SHA aus dem letzten polycrate workspace sync korrelieren können.

Im Polycrate-API-Backend entsteht damit ein zusammenhängendes Bild:

• Workspace-Sync → neue Playbook-Version
• Action Run linux-patch/patch → ausgerollte Änderung
• SSH-Sessions → manuelle Nacharbeiten oder Debugging

Mehr zum Zusammenspiel von Blocks, Workflows und Actions finden Sie in der Blocks-Dokumentation und den Workflows.

NIS‑2 und DSGVO: Was der Audit-Trail abdeckt – und was nicht

Polycrate hilft Ihnen, zentrale Anforderungen aus NIS‑2 und DSGVO abzubilden:

• Nachweisbarkeit von Änderungen: Wer hat wann welche Infrastruktur- oder Konfigurationsänderungen per Ansible ausgerollt?
• Protokollierung von Administratorzugriffen: SSH-Sessions sind zentral erfasst, nicht nur in verstreuten Syslogs.
• Schutz von Zugangsdaten: Workspace-Verschlüsselung und API-basiertes Key-Management reduzieren das Risiko von Klartext-Secrets.
• Tool-Governance: CLI Instance Tracking unterstützt beim Nachweis, dass nur freigegebene Tool-Versionen genutzt werden.

Wichtig ist aber auch, klar zu benennen, was der Scope nicht umfasst:

• Polycrate ersetzt nicht die Protokollierung innerhalb von Business-Applikationen (z.B. wer in einer Fachanwendung Daten geändert hat).
• Polycrate sieht keine Befehle, die völlig an ihm vorbei gehen (z.B. manueller ssh-Aufruf direkt aus einem Terminal, ohne Polycrate-Wrapper).
• Betriebssystem-Logs, Netzwerk-Logs und SIEM-Regeln bleiben weiterhin notwendig – Polycrate liefert ergänzende, stark strukturierte Daten.

In der Praxis ist Polycrate damit ein wichtiger Baustein in einem umfassenden Audit- und Monitoring-Stack, der in SIEM- oder GRC-Systeme integriert wird.

Polycrate vs. plain Ansible: das fehlende Protokoll

Mit plain Ansible könnten Sie einiges davon nachbauen:

• Eine zentrale Bastion, auf der alle Admins sich einloggen, um Playbooks auszuführen.
• Shell-Skripte, die vor und nach ansible-playbook Timestamps loggen.
• Manuelle Konfiguration von SSH-Logging und zentralem Syslog-Sammeln.
• Separates Tool, um Git-Commits mit Deployments zu verknüpfen.

Das ist alles machbar – erfordert aber:

• erheblichen manuellen Aufwand,
• hohe Disziplin im Team,
• und bleibt oft brüchig, wenn neue Tools oder Workflows dazukommen.

Polycrate bringt diese Fähigkeiten integriert mit:

• Die containerisierte Toolchain löst das Dependency-Problem und gibt Ihnen konsistente Ausführungsumgebungen.
• Die Block- und Workspace-Struktur verhindert Playbook-Wildwuchs und macht Automatisierung teilbar.
• Die Polycrate API liefert den kompletten Audit-Trail: Action Runs, SSH, Syncs, CLI-Instanzen, Key-Management.

Sie müssen keine zusätzliche Infrastruktur bauen – nur Ihre bestehenden Workflows konsequent über Polycrate laufen lassen.

Häufige Fragen

Erfasse ich wirklich jede SSH-Session, wenn ich Polycrate einführe?

Polycrate erfasst alle SSH-Sessions, die über Polycrate gestartet werden (z.B. polycrate ssh host). Wenn ein Admin direkt ssh host im Terminal nutzt, ohne Polycrate, sieht die API diese Session nicht.

In der Praxis etabliert man daher einen Prozess:

• Administratorzugriffe auf Produktionssysteme laufen grundsätzlich über Polycrate.
• Direkte SSH-Logins werden organisatorisch untersagt oder stark eingeschränkt.
• Optional wird auf den Zielsystemen zusätzlich erzwungen, dass nur bestimmte Jump-Hosts zugelassen sind, auf denen Polycrate installiert ist.

So wird Polycrate zum natürlichen Einstiegspunkt für Operations – und der Audit-Trail wird vollständig.

Wie integriere ich den Polycrate-Audit-Trail in mein zentrales SIEM?

Die Polycrate API bietet strukturierte JSON-Events für Action Runs, SSH-Sessions, Workspace-Syncs und mehr, siehe API-Dokumentation. Übliche Integrationswege sind:

• Pull: ein zentrales Skript oder Service ruft periodisch neue Events ab und pusht sie ins SIEM.
• Push: ein kleiner Forwarder-Service abonniert Events (oder pollt inkrementell) und leitet sie in Echtzeit weiter.
• Mapping: im SIEM werden korrespondierende Felder (User, Host, Workspace, etc.) auf interne Datenmodelle gemappt.

Durch die klare Struktur lässt sich Polycrate gut in bestehende Use-Cases wie „Privileged Access Monitoring“ oder „Change Tracking“ einbinden.

Werden durch CLI Instance Tracking personenbezogene Daten gespeichert?

Die Polycrate API speichert u.a. Usernamen, Hostnamen und CLI-Versionsinformationen, um Auditierbarkeit sicherzustellen. Wie stark diese Daten als personenbezogen gelten, hängt vom Kontext ab (z.B. Zuordnung zu realen Personen).

Für DSGVO-konforme Nutzung empfehlen wir:

• Klare Information der Mitarbeitenden über die Protokollierung (Transparenz).
• Rollenbasierte Zugriffskontrolle auf Audit-Daten.
• Ggf. Pseudonymisierung von Hostnamen oder User-IDs, sofern mit Ihren Compliance-Vorgaben vereinbar.

ayedo unterstützt Sie dabei, Polycrate so zu konfigurieren und zu integrieren, dass die Anforderungen Ihrer Datenschutzbeauftragten erfüllt werden.

Weitere Fragen? Siehe unsere FAQ

Compliance in der Praxis

Mit Polycrate und der dazugehörigen API erhalten Sie mehr als „nur“ ein Automatisierungs-Tool: Sie bekommen einen Operations-Layer, der technische Exzellenz mit Auditierbarkeit verbindet.

In diesem Beitrag haben Sie gesehen:

• wie Action Runs, SSH-Sessions und Workspace-Syncs zu einem durchgängigen Audit-Trail verschmelzen,
• wie CLI Instance Tracking und zentrales Key-Management helfen, Governance-Vorgaben umzusetzen,
• und wie sich diese Daten nutzen lassen, um NIS‑2- und DSGVO-Anforderungen praktisch umzusetzen – ohne Ihr Team mit zusätzlichem Tool-Wildwuchs zu belasten.

ayedo begleitet Teams genau an dieser Schnittstelle zwischen Automatisierung und Compliance: von der Gestaltung Ihres Platform-Engineering-Ansatzes über die Einführung von Polycrate bis hin zur Integration der Polycrate API in Ihre bestehenden SIEM- und GRC-Systeme.

Wenn Sie sehen möchten, wie der Audit-Trail in Ihrer Umgebung konkret aussehen kann, sind gute nächste Schritte:

• Polycrate API-Dokumentation
• Workshops – geführte Einblicke mit Beispielen aus Ihrem Kontext