Der Weg einer Regel

Eine Regel durchläuft Entwurf → Im Review → Freigegeben → Aktiv. Freigegeben heißt: jemand anderes hat entschieden, dass es die Regel geben darf. Aktiv heißt: der Betrieb hat bestätigt, dass sie auf allen zugeordneten Komponenten tatsächlich umgesetzt ist — der Status springt automatisch, sobald die letzte Komponente auf „umgesetzt" steht, und fällt zurück auf „freigegeben", wenn eine es nicht mehr ist. Der Unterschied macht sichtbar, was sonst unsichtbar wäre: freigegeben, aber nie ausgerollt.

Eine inhaltliche Änderung an einer freigegebenen Regel setzt sie zurück auf Entwurf — die alte Freigabe galt der alten Regel. Bereits umgesetzte Komponenten stehen nach erneuter Freigabe auf „zu ändern", damit der Betrieb den Unterschied nachzieht.

Gelöscht wird nie. Eine nicht mehr benötigte Regel bekommt den Status „gelöscht", bleibt in der Übersicht sichtbar (durchgestrichen) und behält Historie und Kommentare als Nachweis. Was endet, ist ihre Wirkung: kein Export, keine Pfad-Analyse, kein Soll-Ist-Abgleich.

Rezertifizierung: Kampagnen

Ein Ablaufdatum zu verlängern ist eine Entscheidung über einen Kalender. Eine Kampagne stellt die eigentliche Frage, Regel für Regel: wird sie noch gebraucht, stimmt ihr Zuschnitt, gibt es ihren Verantwortlichen noch? Genau das verlangt eine Prüfung nach BSI NET.3.2 — und genau das kann ein Datumsfeld nicht beantworten.

So läuft eine Kampagne ab:

1. Ein Change Approver startet sie: Name, Stichtag und Umfang — all (alle Regeln in Kraft), zone:Z040 (alle Regeln aus oder in die Zone) oder component:3 (alle Regeln dieser Komponente). Die Liste wird beim Start eingefroren; später angelegte Regeln gehören zur nächsten Kampagne.
2. Jede Regel steht mit ihrem Verantwortlichen auf der Liste. Der Filter „Nur meine Regeln" zeigt jedem seinen Anteil. Verantwortliche, die keinem aktiven Benutzer entsprechen, werden markiert — diese Regeln bearbeitet sonst niemand, und oft ist das der erste Hinweis, dass ein Owner die Organisation verlassen hat.
3. Pro Regel fällt eine von drei Entscheidungen: „Weiterhin nötig" bestätigt die Regel (auf Wunsch mit neuem Ablaufdatum, sonst läuft sie trotz Bestätigung ab). „Nötig, aber fehlerhaft" schickt sie mit Pflicht-Begründung zurück ins Review — der Mittelweg, damit niemand eine fast richtige Regel durchwinken oder stilllegen muss. „Nicht mehr nötig" deaktiviert sie und setzt die Komponenten auf „zu löschen".
4. Jede Entscheidung wird namentlich festgehalten und kann nicht überschrieben werden — wer es versucht, erfährt, wer zuerst entschieden hat. Auf der Regel selbst steht danach, wer sie zuletzt bewusst bestätigt hat und wann.
5. Zum Stichtag zeigt der Bericht (CSV), wer was entschieden hat und was offen ist. Offene Einträge bleiben beim Schließen offen — eine unentschiedene Regel ist ein Befund, kein Schönheitsfehler. Der Bericht ist das, was ein Prüfer tatsächlich sehen will.

Die Abschnitte „Abgelaufen" und „Läuft ab" darunter sind davon unabhängig: das ist die tägliche Ablaufkontrolle, die weiterläuft wie bisher.

Notfall-Änderung

Um drei Uhr nachts, Anwendung steht, kein Change Approver erreichbar: die Regel wird auf der Firewall geöffnet — das verhindert kein Werkzeug. Was Permitra verhindert, ist, dass sie unaufgezeichnet bleibt. Über „Notfall-Änderung" wird die bereits gesetzte Regel nachträglich dokumentiert, mit Pflicht-Begründung: Störung, Ticket, wer erreichbar war.

Die Regel geht ins Review und trägt eine Uhr: ohne nachträgliche Freigabe innerhalb des Zeitfensters (Standard 24 Stunden) deaktiviert sie sich selbst, und der Betrieb wird angewiesen, sie zurückzubauen. Bis dahin steht sie deutlich sichtbar auf dem Dashboard.

Der Weg ist bewusst eng statt bequem: keine Abkürzung an der Freigabe vorbei, sondern ein eigener Audit-Eintrag — damit zählbar bleibt, wie oft das vorkommt. Zweimal im Jahr ist ein funktionierender Prozess; wöchentlich ist ein Befund.

Ping-Basisregel

Wenn ein System nicht antwortet, ist die erste Frage nicht „welcher Port", sondern: kommt das Netz überhaupt dort an? Ohne Antwort beginnt die Suche an der Firewall — ausgerechnet an der Stelle, die es längst hätte beantworten können. Eine Ping-Basisregel beantwortet es: eine stehende Regel, die jeder Adresse der Quellzone erlaubt, jede Adresse der Zielzone anzupingen. Sie macht aus „das Netz ist kaputt" ein „der Weg ist offen, der Dienst ist unten" — der Unterschied zwischen einem Change und einem Neustart.

Angelegt wird sie über „Neue Regel" mit der Option „Ping-Basisregel". Adressen gibt es keine — die Regel gilt für ganze Zonen, deshalb werden die beiden Zonen ausgewählt statt abgeleitet. Alles andere bleibt wie bei jeder Regel: Freigabe, Export, Rezertifizierung, Ablaufdatum.

Zulässig ist sie nur unter vier Bedingungen, und die sind der eigentliche Punkt:

• Nur zwischen internen Zonen. Unterhalb der P-A-P-Struktur vertrauen sich die Zonen ohnehin so weit, dass die Matrix eine Freigabe trägt. Zur P-A-P-Schicht und nach außen ist ICMP Aufklärung — die erste Frage eines Angreifers ist dieselbe wie die des Betriebs, und dort beantworten wir sie nicht.
• Nur auf einer Beziehung, die die Matrix bereits erlaubt. Die Basisregel setzt auf einer freigegebenen Beziehung auf, sie schafft keine. Ob zwei Zonen miteinander reden dürfen, bleibt eine Matrix-Entscheidung mit zwei Freigaben.
• Nur Echo. Nicht jeder ICMP-Typ: kein Redirect, kein Timestamp, keine Address Mask. Der Export sagt entsprechend junos-ping und nicht junos-icmp-all — sonst würde die Regel etwas anderes dokumentieren, als auf dem Gerät steht.
• Nur in eine Richtung. Die Matrix-Zelle ist gerichtet, die Regel auch. Die Antwort auf den Echo Request kommt über die Session zurück, die die Firewall ohnehin führt; in die Gegenrichtung pingen ist eine zweite Frage mit einer eigenen Zelle.

Die Firewalls, auf denen sie entsteht, ergeben sich aus den beiden Zonen und der Topologie dazwischen — also auch Cluster, die nur auf dem Weg liegen und an keiner der beiden Zonen hängen.

In der Risikobewertung erscheint sie als eigener Befund („Ping-Basisregel") mit niedriger Stufe — nicht als „zu breite Regel". Eine Regel, die per Ausnahme breit sein darf, als Fehler zu melden, hieße, die Bewertung wüsste nicht, was freigegeben wurde; und ein Kriterium, das bei jeder Regel einer Art anschlägt, überliest man. Genannt wird sie trotzdem: eine stehende Regel, die niemand sieht, ist der Weg, auf dem eine ihren Grund überlebt.

Zonen, Netzwerke und die Matrix

Quell- und Zielzone einer Regel werden nicht eingegeben, sondern abgeleitet: jedes Netz gehört zu genau einer Sicherheitszone (Seite „Netzwerke"), und die Adressen der Regel bestimmen ihre Zonen. Wird eine Adresse abgelehnt („keiner Zone zugeordnet"), fehlt die Netz-Zuordnung — sie wird einmal auf der Netzwerke-Seite gepflegt und gilt dann für alle künftigen Regeln.

Die Kommunikationsmatrix legt je Zonenpaar fest, ob Regeln überhaupt zulässig sind. Steht die Beziehung auf Block (oder ist ungepflegt, bei aktivem Default-Deny), wird die Regel mit einer Meldung abgewiesen — die Matrix ändert man nicht nebenbei, sondern per Antrag mit zwei Freigaben durch verschiedene Change Approver.

Ein Zonenübergang läuft immer über eine Firewall (BSI-Prinzip): eine zonenübergreifende Regel, deren Komponenten alle ACI sind, wird abgelehnt. ACI-Contracts sind das Werkzeug innerhalb einer Zone.

Wird ein Netz in eine andere Zone verschoben, werden alle betroffenen Regeln neu bewertet: Zonen neu abgeleitet, Matrix neu geprüft. Regeln, die dadurch unzulässig werden, gehen als Löschvorschlag ins Review — die Freigabe ist dann die Freigabe ihres Rückbaus.

Pfad-Analyse: welche Firewalls liegen dazwischen

Die Analyse beantwortet für ein Adresspaar: kommt der Verkehr durch, über welche Firewalls, und welche Regel erlaubt ihn dort. Mehrere Firewalls hintereinander sind im Unternehmen der Normalfall — der Weg wird deshalb aus den dokumentierten Verbindungen zwischen den Komponenten abgeleitet (Seite „Komponenten": OSPF, BGP, Transfernetze). Die Adress-Zuordnung sagt nur noch, hinter welcher Firewall eine Adresse hängt; alles dazwischen ergibt sich aus der Topologie. Eine Station, hinter der keine der beiden Adressen liegt, ist als Transit gekennzeichnet.

Drei Aussagen kommen erst dadurch zustande. Keine Route: Wenn die Topologie die beiden Komponenten nicht verbindet, sagt die Analyse das — statt einer Reihenfolge, die wie ein funktionierender Pfad aussieht. Redundante Routen: Gibt es zwei gleich kurze Wege, werden beide gezeigt, denn eine Regel, die nur auf einem liegt, trägt bis zum Schwenk. Und die Cluster einer Route ohne freigegebene Regel werden benannt. Sind gar keine Verbindungen hinterlegt, sagt die Analyse auch das und ordnet ersatzweise nach Nord-Süd-Ebene — „nicht dokumentiert" ist etwas anderes als „nicht erreichbar".

Soll-Ist-Abgleich und Deckungsgrad

Der Abgleich vergleicht die dokumentierten Regeln mit einer hochgeladenen Gerätekonfiguration (Seite „Berichte") und beantwortet beide Richtungen. Erstens: sind meine Regeln angekommen? missing = freigegeben, aber nicht auf dem Gerät; stale = auf dem Gerät, aber nicht mehr freigegeben; unknown = eine SR-ID, die Permitra nicht kennt.

Zweitens die Frage, für die Permitra existiert: ist jede Regel auf dem Gerät durch eine freigegebene Sicherheitsregel begründet? Regeln ohne SR-ID — von Hand geöffnet, aus der Zeit vor Permitra — erscheinen als unbegründet, mit Name und Zeilennummer. Daraus entsteht der Deckungsgrad auf dem Dashboard.

Die Zahl ist ehrlich, oder sie ist nichts: sie erscheint nie ohne die Angabe, auf wie vielen Komponenten gemessen wurde. Komponenten ohne Konfiguration oder mit unlesbarem Format werden benannt statt weggemittelt — „kann ich nicht lesen" wird nie zu „alles in Ordnung". Eine laufende Notfall-Änderung gilt nicht als stale: sie liegt absichtlich auf dem Gerät, solange ihr Zeitfenster offen ist.

Risikohinweise

Regeln werden gegen sichtbare Kriterien geprüft: any-zu-any, any als Quelle, sehr breite Netze, riskante Dienste (Portliste vom Admin pflegbar, Bereiche wie 20-25 werden aufgelöst), any-Dienst über Zonengrenzen — und eine Regel ohne Protokollierung in eine Zone mit hohem Schutzbedarf.

Der Schweregrad steigt mit dem Schutzbedarf der Zielzone und bei exponierter Quelle. Hinweise blockieren nichts: sie stehen beim Review sichtbar dabei, damit die Entscheidung sie einbezieht. „Nach welchen Kriterien?" auf der Regelseite zeigt den vollständigen Maßstab — ein fehlender Hinweis heißt „nicht auf der Liste", nicht „harmlos".

Protokollierung, deny und reject

Jede Regel legt fest, was sie protokolliert: keine, standard (jeder Treffer) oder detailliert (inklusive Sitzungsende — bei Juniper session-init session-close, bei Check Point „Detailed Log"). Der Abgleich mit der Zonen-Schutzstufe läuft über die Risikohinweise.

Bei Verweigerung gibt es zwei Arten: deny (drop) verwirft still — der Aufrufer läuft in einen Timeout. reject antwortet mit ICMP unreachable oder TCP RST — der Aufrufer bekommt sofort einen Fehler. Faustregel: nach außen Stille, nach innen eine Antwort; ein Drop im eigenen Netz macht aus einem Konfigurationsfehler ein 30-Sekunden-Hängen und ein Ticket. Plattformen ohne reject (z. B. Cisco Extended ACL) erzeugen deny — das ist die Grenze des Geräts, kein verlorener Wert.

Exporte

Permitra schreibt nie selbst auf Geräte. Es erzeugt die Konfiguration zum Übernehmen: Juniper set-Kommandos, Check Point mgmt_cli und Management-API, EPG-basierte ACI-Contracts, Host-Firewalls, Capirca/Aerleon-Ziele, CSV/JSON.

In einen Export kommen nur Regeln in Kraft (freigegeben oder aktiv) — auch wenn explizite IDs angegeben werden: ids= wählt aus, *welche* Regeln gemeint sind, nicht ob ihr Status noch zählt. Eine Vorschau nicht freigegebener Regeln braucht only_approved=false und wird im Audit-Log als solche vermerkt. Jeder Export schreibt einen Audit-Eintrag.

Nachweisbericht für Prüfungen

Eine Prüfung fragt nach einem Dokument: alle Änderungen an Zone Z im Zeitraum T, mit Antragsteller, Freigeber, Begründung und Datum. Unter Berichte → Nachweisbericht wird genau das erzeugt — Zeitraum wählen, optional auf eine Zone oder Anwendung eingrenzen. Über „Drucken / PDF" entsteht daraus das Dokument zum Weitergeben, per CSV die sortierbare Fassung.

Der Bericht sagt außerdem, wofür er einstehen kann: das Ergebnis der Hash-Kettenprüfung, und ob das Audit-Log den Zeitraum noch abdeckt. Regel- und Matrixänderungen unterliegen keiner Aufbewahrungsfrist und sind immer vollständig; das Audit-Log kann durch die Aufbewahrungsfrist gekürzt worden sein (siehe Rezertifizierung/Aufbewahrung). Reicht der Zeitraum dahinter zurück, steht das als Hinweis im Bericht — ein Dokument, das eine Lücke verschweigt, wäre schlechter als keines.

Anwendung außer Betrieb nehmen

Wird eine Anwendung abgelöst, bleiben ihre Regeln sonst stehen — die Anwendung ist weg, die Öffnungen sind es nicht. Das ist eine der häufigsten Ursachen, warum Regelwerke verrotten. Über Regeln → Anwendung außer Betrieb nehmen schlägt ein Architekt alle in Kraft befindlichen Regeln einer Anwendungs-ID zur Entfernung vor.

Es wird dabei nichts entfernt und nichts deaktiviert. Jede Regel geht mit der Begründung zurück ins Review und wird einzeln entschieden; erst die Freigabe deaktiviert sie und setzt die Komponenten auf „zu entfernen". Vor dem Auslösen zeigt eine Vorschau, welche Regeln betroffen wären — und welche nicht (Entwürfe etwa stehen auf keinem Gerät). Das Vier-Augen-Prinzip bleibt: Wer die Außerbetriebnahme startet, gilt als Einreicher und kann die Entfernungen nicht selbst freigeben.

Rollen und Vier-Augen-Prinzip

Architekten legen Regeln an und reichen sie ein. Change Approver entscheiden: eine Freigabe je Regel-Review, zwei verschiedene Approver je Zonen-, Netz- oder Matrixantrag; sie starten und schließen außerdem die Rezertifizierungs-Kampagnen. Betrieb pflegt den Umsetzungsstatus je Komponente, exportiert und lädt Gerätekonfigurationen für den Abgleich. Admins sind ausschließlich für Installation und Verwaltung zuständig — bewusst kein Superuser: keine Regelansichten, keine Freigaben, keine Rezertifizierung.

Ein Konto kann mehrere Rollen haben; seine Rechte sind deren Vereinigung — kleine Teams haben nicht vier Personen für vier Rollen. Das Vier-Augen-Prinzip bleibt davon unberührt, denn die Prüfungen hängen am handelnden Konto, nicht an der Rolle: Wer eine Regel beantragt, erstellt oder eingereicht hat, kann sie nicht selbst freigeben — auch nicht, wenn dasselbe Konto zusätzlich Approver ist. Und die zwei Freigaben eines Zonen-, Netz- oder Matrixantrags müssen von zwei verschiedenen Konten kommen. Zwei Hüte auf einer Person bleiben ein Augenpaar.

Das Audit-Log hält jede Anmeldung, jede Verwaltungsaktion und jeden Datenzugriff fest, verkettet mit SHA-256-Hashes und auf Wunsch an ein SIEM zugestellt. Einträge erscheinen in der Sprache der Instanz — auch rückwirkend nach einem Sprachwechsel.