Zusammenfassung

  • Ein individueller IETF-Entwurf vom 27. Oktober macht Verwaltungsgebiet, Eigentümer, Verfasser, Sprache und Regelinhalt im YANG-Policypaket verpflichtend. Ob die empfangende Verwaltung die Befugnis des Absenders für dieses Gebiet prüft, steht im Text unter MAY.
  • Das Paket kann eine gültige Herkunftssignatur tragen und dennoch an einer fremden Entscheidungsgrenze stehen. Über die Installation entscheidet die empfangende Institution; ihre Vollmacht muss mit der konkreten Fassung dokumentiert werden.

Ein Lieferschein ist noch keine Dienstanweisung

Im Rechenzentrum kommt eine neue Policy an. Die Signatur stimmt, die Pflichtfelder sind ausgefüllt, und der angegebene Eigentümer klingt plausibel. Für ein automatisiertes System ist das eine Einladung, die Regel an den nächsten Entscheidungspunkt weiterzureichen. Für den Betreiber des Zielnetzes beginnt an dieser Stelle erst die Frage, die den Betrieb beherrscht: Wer durfte diesem Absender das Recht geben, in unserem Verwaltungsgebiet Regeln zu setzen?

Der individuelle Entwurf Model for distributed policy sharing beschreibt einen YANG-Behälter für ein einzelnes Policy-Artefakt. area, language, policy-content, owner und author sind Pflichtfelder. origin und eine Provenienzsignatur erscheinen im Modell als optionale Felder. Der Regeltext selbst ist für den Behälter opak. Er kann eine Rego-Regel und eine Netzwerksicherheitsregel nach derselben Verwaltungsform transportieren, ohne deren Semantik zu vereinheitlichen.

Das ist technisch sauber. Institutionell entsteht eine gefährliche Abkürzung, wenn die Metadaten zu einem Mandat erklärt werden. Der Absender schreibt den Wert von owner selbst in das Paket. Das Feld author benennt einen Urheber, nicht den örtlichen Prinzipal. area zeigt, wo die Regel wirken soll, aber keine Einwilligung dieses Gebiets. Eine Signatur nach dem herangezogenen YANG-Provenienzentwurf könnte Ursprung und Unversehrtheit binden. Die Erlaubnis, eine fremde Domäne zu steuern, stammt aus deren eigener Delegationsordnung.

Die Zeichnung verspricht mehr als das Modalverb

Abschnitt 6.1 gibt dem Policy Administration Point, PAP, Schemaprüfung und Lebenszyklusverwaltung. Vor Annahme oder Verteilung eines Artefakts MAY er einen Policy Decision Point befragen, ob der angegebene Eigentümer oder Einreicher für das betroffene Gebiet Regeln definieren oder ändern darf. Das Schaubild in Abschnitt 6.2 zeigt einen auffälligen „Governance Authorization Check“ im PAP. Wer nur das Schaubild betrachtet, hält die Schranke womöglich für serienmäßig. Das Wort MAY überlässt die Einrichtung der Schranke jedoch dem Betreiber.

Lokale Freiheit ist bei verschiedenen Vertrauensordnungen nachvollziehbar. Sie verlangt aber eine sichtbare Entscheidung. Ein Empfänger muss vorab definieren, welche Stelle Vollmachten für welches area erteilt, wie die Identität gebunden wird, wann die Vollmacht endet und wer eine bereits eingespielte Regel zurückrufen kann. Der Laufzeit-PDP beantwortet später Anfragen anhand der Regel. Seine korrekte Ausführung heilt keinen unbefugten Einbau.

Eine Mitteilung der Autorin an die NMOP-Liste kündigt eine Demonstration in zwei Domänen an. In der ersten soll Rego über einen OPA-basierten PDP wirken; in der zweiten soll eine an RFC 9061 angelehnte Policy einen IPsec-Tunnel zwischen bestimmten Knoten erzwingen. Wenn beides läuft, ist die Verteilung über unterschiedliche Sprachen hinweg gezeigt. Ob die jeweilige Domäne den Verfasser autorisiert hat, bleibt eine weitere Messung. Die Nachricht berichtet von einem Plan, nicht von einem abgeschlossenen Versuch.

Der IETF Datatracker führt das Papier als aktiven individuellen Internet-Draft mit dem Status I-D Exists. Die hier analysierte Entscheidung liegt also im Vorschlag. Der Entwurf selbst benennt die Vertrauenslücke bei mehreren Verwaltungsdomänen: Eine identifizierbare Quelle kann außerhalb ihres Zuständigkeitsbereichs handeln.

Der Aktenvermerk muss bis zum Rückbau reichen

Der Entwurf bestimmt keinen Transportweg. Er erlaubt dem PAP mit MAY, frühere Fassungen extern zu verwahren und Lebenszyklusereignisse in einem append-only Buch zu erfassen. Für einen prüfbaren Betrieb gehört in denselben Vorgang: Hash der angenommenen Fassung, verifizierter Schlüssel, behaupteter Eigentümer, örtlich anerkannte Vollmacht, genauer Geltungsbereich, Installationsziel und Rückbauentscheidung. Ein Versandprotokoll ohne die Vollmacht beweist nur die Reise des Pakets.

RFC 2904 trennt Autorisierungsfunktionen als Grundmodell. Der konkrete Grenzentscheid bleibt bei der empfangenden Einrichtung. Wer ihn in einem grün leuchtenden Herkunftssiegel versteckt, spart einen Arbeitsschritt und verkauft die spätere Aufklärung gleich mit.

Quellen