Permitra – Zentrale Verwaltung von Sicherheitsregeln

Warum Permitra? – Die Geschichte dahinter

Permitra ist aus der Praxis entstanden: Der Autor hat als Solution Architect viele Cloud-Infrastrukturprojekte umgesetzt – und jedes einzelne wurde von Excel-Listen voller Sicherheitsregeln begleitet. Permitra ist die daraus gewachsene Vorstellung, wie sich Sicherheitsregeln stattdessen sauber planen, freigeben und dokumentieren lassen.

Transparenz: Permitra wurde mit Claude, dem KI-Coding-Assistenten von Anthropic, entwickelt. Mit eingeschränkten eigenen Programmierkenntnissen wurde es so möglich, diese Vorstellung in eine funktionierende Lösung zu übersetzen: Die Fachlichkeit, Architekturprinzipien und Workflows kommen aus der Projektpraxis – die Umsetzung entstand im iterativen Dialog mit der KI. Auch deshalb ist Permitra Open Source: damit erfahrene Entwickler den Code kritisch prüfen und die Ideen als Inspiration nutzen können.

Funktionen

Regel-Workflow mit Freigaben

Eindeutige Rule-IDs, Entwurf → Im Review → Freigegeben → Aktiv, wobei „aktiv" erst gilt, wenn der Betrieb die Umsetzung auf allen Komponenten bestätigt hat. Versionshistorie, Kommentare, Rezertifizierung ablaufender Regeln. Gelöscht wird nie: eine nicht mehr benötigte Regel bekommt den Status „gelöscht" und bleibt sichtbar. Für den Notfall um drei Uhr nachts gibt es einen eigenen, bewusst engen Weg: die bereits gesetzte Regel wird nachträglich dokumentiert und verfällt ohne Freigabe von selbst.

Sicherheitszonen nach BSI

Zonen-Kommunikationsmatrix (Allow/Block) mit P-A-P-Modell: Zonenübergänge laufen immer über eine Firewall, ACI wirkt nur innerhalb einer Zone. Matrix-Änderungen brauchen zwei Freigaben.

Netzwerk-Registry

Jedes Netz gehört zu genau einer Zone. Quell- und Ziel-Zonen einer Regel werden automatisch aus den Adressen abgeleitet – Änderungen an der Zuordnung durchlaufen den Freigabe-Workflow.

Automatische Komponenten-Ermittlung

Aus Quelle und Ziel ermittelt Permitra, auf welchen Firewall-Clustern oder ACI-Fabrics eine Regel umzusetzen ist – inklusive Umsetzungsstatus für den Betrieb.

Exporte für die Praxis

Juniper-SRX-set-Kommandos, Check Point mgmt_cli und Management-API, Cisco-ACI-Contracts (EPG-basiert, inkl. PBR Service Graphs), Host-Firewalls (nftables, firewalld, iptables), CSV und JSON. Über die integrierte Capirca-/Aerleon-Anbindung zusätzlich Cisco IOS/ASA, Palo Alto, zonenbasiertes SRX, iptables – oder direkt Capirca-Policy-YAML für bestehende Pipelines.

Analyse & Drift

Adress-Suche und Pfad-Analyse: Der Weg wird aus den dokumentierten Verbindungen zwischen den Firewalls abgeleitet – mehrere Firewalls hintereinander sind im Unternehmen der Normalfall. Gibt es keinen Weg, sagt die Analyse das; gibt es zwei redundante, zeigt sie beide, denn eine Regel auf nur einem trägt bis zum Schwenk. Dazu Konflikt- und Risiko-Warnungen, Soll-Ist-Abgleich gegen hochgeladene Gerätekonfigurationen. Der Abgleich beantwortet beide Richtungen: sind meine Regeln angekommen – und ist umgekehrt jede Regel auf dem Gerät durch eine freigegebene Sicherheitsregel begründet? Und er prüft, ob die Regel auf dem Gerät nur das erlaubt, was freigegeben wurde.

Reports je Anwendung

Jede Regel trägt eine APP-ID; darüber lässt sich ein CSV-Report aller Regeln einer Anwendung erzeugen – praktisch für Audits und Anwendungs-Reviews.

Revisionssichere Protokollierung & SIEM

Anmelde-, Admin- und Zugriffsereignisse werden append-only mit Quell-IP protokolliert und per SHA-256-Hash-Kette gegen Manipulation gesichert – jede nachträgliche Änderung fällt auf, auch direkt in der Datenbank. Die Zustellung an ein SIEM erfolgt zuverlässig (at-least-once) und übersteht Neustarts wie Ausfälle.

Automatisierung: API & NetBox

Read-only API-Tokens binden Ansible/Terraform an; Netz-Prefixe lassen sich direkt aus NetBox importieren (Vorschau vor Übernahme). Authentisierung mit 2FA/Passkeys und Login-Sperre.

Einblicke

Aufnahmen aus der öffentlichen Demo mit Beispieldaten – von der Dashboard-Übersicht bis zur revisionssicheren Protokollierung.

Permitra Dashboard — **Dashboard:** Regeln nach Status, Verteilung je Firewall-Cluster/ACI-Fabric und die letzten Änderungen auf einen Blick.

Regelübersicht — **Regelwerk:** eindeutige Rule-IDs, abgeleitete Quell-/Ziel-Zonen, Dienste, Umsetzungskomponenten und Freigabestatus – filterbar nach APP-ID und Risiko.

**Zonenplan (BSI):** automatisch generierter Netzplan nach dem P-A-P-Modell mit Zonen-IDs, Schutzbedarf und ACI-Kennzeichnung.

Pfad-Analyse — **Analyse:** Pfad-Prüfung Quelle → Ziel über alle beteiligten Firewall-Cluster und ACI-Fabrics, inklusive der passenden Regeln – mit Druck-/PDF-Ausgabe.

**Audit-Log:** revisionssichere Protokollierung von Anmelde-, Admin- und Zugriffsereignissen mit Quell-IP – vollständig über die API an ein SIEM anbindbar.

BSI-Anforderungen: Was Permitra abdeckt – und was (noch) nicht

Permitra orientiert sich an den Anforderungen des BSI IT-Grundschutz an Sicherheitszonen und Regelwerks-Dokumentation. Hier der ehrliche Stand:

✅ Adressiert

Zonen-Dokumentation: Name, Zweck, Verantwortlicher, Schutzbedarf je Schutzziel (C/I/A, Maximumprinzip), P-A-P-Einstufung
Zonenübergänge nur über Firewalls – hart erzwungen (ACI nur intra-zonal)
Minimalprinzip: Allow/Block-Matrix, optional default-deny für ungepflegte Beziehungen
Generierter Zonenplan und Komponenten-Topologie
Regelwerk mit eindeutigen IDs, dienst-genauen Regeln, Versionshistorie und personengebundenen Freigaben
Mehrstufige Freigabe mit Vier-Augen-Prinzip (zwei Approver für Zonen-/Matrix-/Netzwerk-Änderungen)
Ein Konto kann mehrere Rollen haben – kleine Teams haben nicht vier Personen für vier Rollen. Das Vier-Augen-Prinzip bleibt unberührt: die Prüfungen hängen am handelnden Konto, nicht an der Rolle. Zwei Hüte auf einer Person bleiben ein Augenpaar.
Auswirkungsanalyse: Matrix-Änderungen zeigen betroffene Regeln; Allow→Block setzt freigegebene Regeln in den Review
Temporäre Regeln: automatische Deaktivierung nach Ablauf, Rezertifizierung
Soll-Ist-Abgleich (Drift) gegen Gerätekonfigurationen – inklusive Deckungsgrad: welche Regeln auf dem Gerät durch keine freigegebene Sicherheitsregel begründet sind. Und eine Ebene tiefer: erlaubt die Regel auf dem Gerät nur das, was freigegeben wurde? Enger ist in Ordnung, weiter ist ein Befund – eine im Störfall aufgeweitete Regel behält ihre ID und liest sich sonst grün.
Anwendung außer Betrieb nehmen: wird eine Anwendung abgelöst, werden alle ihre Regeln zur Entfernung vorgeschlagen – einzeln zu entscheiden, mit Vorschau, und wer es startet kann die Entfernungen nicht selbst freigeben
Rollback auf eine frühere Regel-Version (als neue Version, die Historie bleibt vollständig)
Notfall-Änderung: eine bereits auf der Firewall geöffnete Regel wird nachträglich dokumentiert – Begründung Pflicht, geht ins Review und deaktiviert sich selbst ohne nachträgliche Freigabe; eigener Audit-Eintrag, damit zählbar bleibt, wie oft das vorkommt
Verschlüsselte Backups (gpg) mit erprobtem Restore-Weg – der Dump enthält Passwort-Hashes, TOTP-Seeds und die Audit-Kette
Erzwingbare Pflichtfelder je Regel: Begründung, Verantwortlicher und Gültigkeit (administrativ schaltbar)
Risikoanalyse: Warnungen bei any-to-any und riskanten Diensten, CIA-gewichtete Bewertung
Revisionssicheres Audit-Log: Anmelde-, Admin- und Zugriffsereignisse mit Quell-IP, append-only mit Soft-Delete
Aufbewahrungsfrist für das Audit-Log: abgelaufene Abschnitte werden hinter einem Siegel gelöscht, das die Kette nachweisbar hält – personenbezogene Daten verschwinden, der Nachweis bleibt prüfbar. Ohne konfigurierte Frist wird nichts gelöscht.
Nachweisbericht für Prüfungen: alle Änderungen eines Zeitraums mit Antragsteller, Freigeber, Begründung und Datum – inklusive Kettenprüfung und der Angabe, ob das Audit-Log den Zeitraum noch abdeckt
Manipulationserkennung per Hash-Kette (SHA-256): jede Änderung, Umsortierung oder Entfernung eines Eintrags wird erkannt – auch direkt in der Datenbank
Zuverlässige SIEM-Zustellung (at-least-once): Ereignisse überstehen Neustarts und Ausfälle des SIEM und werden in Reihenfolge nachgeliefert (Syslog/Webhook)
E-Mail-Benachrichtigungen für Review, Freigabe und Rezertifizierung; Aktivierung/Reset
Authentisierung: 2FA (TOTP) und Passkeys, Login-Sperre nach Fehlversuchen, rollenbasierte Rechte
Automatisierung: read-only API-Tokens (Ansible/Terraform) und NetBox-Import der Netz-Prefixe

🟡 Teilweise

Change-Management: generischer Webhook vorhanden, konkreter ServiceNow-Adapter offen

🔴 Nicht adressiert

AD/LDAP-Anmeldung (lokale Konten mit 2FA/Passkeys vorhanden)
Nutzungsbasierte Erkennung veralteter Regeln (Hit-Counter der Geräte) – erfordert Geräte-Adapter
Bewusste Grenzen: Permitra schreibt nie selbst auf Geräte; Router/Switches mit ACLs und reine FQDN-Regeln sind nicht abgebildet

Die offenen Punkte sind als Work Items im Projekt-Backlog erfasst und werden schrittweise umgesetzt.

Live-Demo

Die öffentliche Demo läuft mit fiktiven Beispieldaten (12 Zonen, rund 100 Regeln, 6 Sicherheitskomponenten) und wird jede Nacht zurückgesetzt.

demo.permitra.de

Benutzer – zwei je Rolle, damit sich die Vier-Augen-Wege wirklich durchspielen lassen: einer beantragt, der andere gibt frei: architekt, architekt2, betrieb, betrieb2, approver, approver2, admin, admin2
Dazu doppelrolle – ein Konto mit zwei Rollen (Architekt und Change Approver). Es darf fremde Regeln freigeben, die selbst beantragten aber nicht.
Passwort jeweils: Benutzername + 123
Oberfläche auf Deutsch oder Englisch – die Sprache legt der Administrator für die ganze Instanz fest, damit Screenshots, Schulung und Support dieselben Begriffe verwenden; die Demo läuft auf Deutsch

Firewall-Regeln und ACI-Contracts zentral planen, prüfen und dokumentieren

Was ist Permitra?