Zusammenfassung

  • RFC 9641 modelliert benannte Zertifikats- und Public-Key-Bags, zentrale Verweise und Inline-Definitionen; NACM schützt den Managementpfad, nicht automatisch jeden Speicher- oder Privilegienpfad.
  • Ein gültiger Leafref zeigt, dass ein Konfigurationsobjekt auflösbar ist. Er zeigt nicht, welcher Anker in einer Sitzung verwendet oder warum ein Peer angenommen wurde.
  • Der vollständige Beleg verbindet Änderungsidentität, Freigabe und Speicherintegrität mit exaktem Anker, Peer, Zertifizierungspfad, Uhrzeit, Dienstnamen, Zweck, Sperrstatus, Prüfergebnis und Autorisierung.

Der Änderungsversuch über NETCONF wurde abgewiesen. nacm:default-deny-write hatte gegriffen. Im Kontrollbericht stand danach: „Truststore gegen unbefugte Änderung geschützt.“

Die Aussage galt nur für den beobachteten Pfad. Ein privilegierter lokaler Dienst, ein Paket-Update, eine Datenbankwiederherstellung oder ein beschädigtes Speichermedium konnten denselben öffentlichen Schlüssel außerhalb dieser NACM-Entscheidung verändern. Der verweigerte API-Aufruf war starke Evidenz für eine Tür, nicht für den gesamten Raum.

RFC 9641 zieht diese Grenze ausdrücklich. Das Modul ietf-truststore stellt benannte Bags für Zertifikate und rohe öffentliche Schlüssel bereit. Andere YANG-Modelle können zentrale Objekte referenzieren oder Material inline definieren. Die Spezifikation regelt Managementzugriff und Darstellung, kann aber Schutz ruhender Daten nicht selbst vorschreiben.

Default deny ist ein Ausgangspunkt

RFC 9641 wurde im Oktober 2024 als Standards-Track-RFC der IETF-Arbeitsgruppe NETCONF veröffentlicht. Truststore-Knoten und ihre Verweise tragen nacm:default-deny-write, weil selbst öffentliches Schlüsselmaterial die Sicherheitslage eines Systems drastisch ändern kann.

Nach RFC 8341 beginnt ein gewöhnlicher Schreibzugriff damit bei der Ablehnung, sofern keine spezifischere Regel ihn erlaubt. Für einen Änderungsbeleg braucht es dennoch die authentisierte NETCONF- oder RESTCONF-Identität, den geschützten Kanal, die aktive NACM-Regelversion, die zutreffende Regel, Pfad und Operation, alten und neuen Wert, fachliche Freigabe, Commit sowie die operationale Projektion.

RFC 8342 hilft, intended, system und operational auseinanderzuhalten. Es beweist nicht automatisch, dass ein beabsichtigter Zustand in jedem laufenden Prozess angekommen ist. Der Beleg muss den Übergang beobachten.

Ruhende Daten haben eine andere Angriffsfläche

RFC 9641 stellt klar, dass Management-APIs Daten auf dem Transportweg und den Zugriff durch diese APIs behandeln. YANG kann nicht festlegen, wie ein Truststore in Datei, Datenbank, Firmware oder Backup geschützt wird. Die Implementierung muss unbefugte Änderungen verhindern.

Das verlangt eigene Evidenz: Eigentümer und Berechtigung lokaler Prozesse, Dateisystem- oder Datenbankkontrollen, signierte Pakete, Integritätsmessungen, Backup-Herkunft, Wiederherstellungsfreigabe und Alarme bei Abweichungen. Ein Angreifer muss nicht NACM überwinden, wenn eine andere Schreibfläche offensteht.

Umgekehrt beweist eine lokale Integritätsmessung noch nicht, dass eine Managementänderung fachlich berechtigt war. Beide Kontrollen ergänzen sich. Wer sie zu „Truststore geschützt“ zusammenzieht, verliert die Information, welche Realität tatsächlich geprüft wurde.

Ein Bag benennt Material, nicht die ausgeführte Einschränkung

Zertifikats- und Public-Key-Bags sollen einem gemeinsamen Zweck dienen. Beim Zertifikats-Bag sollte dieser Zweck beschrieben sein; beim Public-Key-Bag muss er beschrieben sein. Das ist eine wichtige Governance-Anforderung, aber Beschreibungstext führt keine Prüfung aus.

Ohne Einschränkungen des konsumierenden Kontexts oder zusätzlicher Richtlinien sind konfigurierte Vertrauensanker implizit für Pfade vertrauenswürdig, die beliebige Namen und Zwecke tragen können. Das generische Modell begrenzt nicht selbst Dienstnamen, Operationen oder Zertifizierungspfade. TLS-Gruppierungen aus RFC 9645 können eine Auswahlstelle liefern; die konkrete Implementierung muss ihre Regeln trotzdem nachweisen.

Der Bag-Name „Produktionsserver“ prüft weder DNS-Namen noch Extended Key Usage, Algorithmen oder Sperrstatus. Ein roher öffentlicher Schlüssel folgt zudem einem anderen Verfahren als ein X.509-Pfad. Ein belastbarer Bericht übernimmt daher nie die Bag-Beschreibung als Ergebnis.

Zentral und inline verteilen Verantwortung anders

Sind die entsprechenden Features vorhanden, verlangen die inline-or-truststore-Gruppierungen eine Wahl zwischen Inline-Material und zentralem Verweis. Beide Varianten können heute dieselben Bytes enthalten. Morgen kann nur eine aktualisiert sein.

Zentrale Bags ermöglichen schnelle, konsistente Rotation. Sie vergrößern zugleich den Radius einer Fehländerung. Inline-Anker begrenzen unmittelbare Auswirkungen, driften aber leichter und können eine Rücknahme überleben. Die Architekturfrage lautet nicht pauschal „zentral oder lokal“, sondern: Wer ändert, welche Verbraucher erben, welches Rollback existiert und wie wird die laufende Wirkung belegt?

Der Ereignisbeleg muss den Verweis bis zu Objekt-ID, Bytes oder Fingerabdruck, Inhalts-Hash, Datastore-Ursprung, Verbraucherpfad und Auflösungszeit verfolgen. Ein unveränderter Bag-Name kann viele Versionen überdauern und ist allein kein historischer Nachweis.

System-Ursprung ist keine Lieferkettenattestierung

Geräte können eingebaute Anker für Herstellerdienste, sicheres Bootstrap oder öffentliche Zertifizierungsstellen bereitstellen. RFC 9641 sieht sie in operational und, soweit vorhanden, im system-Datastore mit System-Ursprung vor. Das trennt Herstellerzustand von einer Betreiberänderung.

Wie diese Anker gesetzt oder geändert werden, bleibt implementationsspezifisch. system beweist nicht, wer das Fertigungsabbild genehmigte, welcher Build den Anker einführte, wie das Update autorisiert wurde oder ob ein Verbraucher ihn auswählte. Bei sicherer Zero-Touch-Bereitstellung nach RFC 8572 kann genau diese erste Vertrauensentscheidung spätere Kontrolle delegieren.

Eine Ablaufmeldung ist ein Signal

Unterstützt die Implementierung das Feature, kann ein Zertifikat vor oder bei Ablauf eine certificate-expiration-Meldung auslösen. Die Meldung beweist weder Zustellung noch Quittierung, Austausch, Referenzumschaltung oder erste erfolgreiche Nutzung.

Ein geschlossener Ablaufprozess bindet Feature, Abonnement, Ereignis, Empfänger, Quittung, Ersatzobjekt, Freigabe, Deployment, Auflösung und anschließende Validierung. Ein zentrales Bag kann aktuell sein, während ein Inline-Verbraucher alt bleibt. Ein noch gültiges Zertifikat kann aus anderen Gründen scheitern.

Vom Pfad zur erlaubten Handlung

RFC 5280 beschreibt X.509-Pfadvalidierung. Der Prüfer wählt Kandidatenpfade, verarbeitet Einschränkungen und lokale Richtlinien. RFC 6125 trennt die erwartete Dienstidentität von der bloßen Pfadgültigkeit. RFC 8446 liefert den TLS-Sitzungskontext.

Für eine reproduzierbare Entscheidung sind Peer-Zertifikat oder Schlüssel, Sitzung, aufgelöstes Bag und Anker, Kandidaten- und akzeptierter Pfad, Zeit und Uhrquelle, Gültigkeit, Referenzidentität, Vergleichsregel, Key Usage, Extended Key Usage, Namensbeschränkungen, Policies, Algorithmen, erforderliche Sperrinformation, Prüfer und begründetes Ergebnis zu speichern.

Danach folgt Autorisierung. Ein korrekt authentisierter Peer darf möglicherweise Telemetrie lesen, aber keine Routing-Konfiguration ändern. Die erlaubte Handlung braucht einen eigenen Beleg; Authentisierung darf nicht als pauschale Vollmacht erscheinen.

Den Annahmebeleg zusammensetzen

Zuerst Modulrevision, Features, Pfad und Modus—inline, zentral oder eingebaut—erfassen. Intended-, System- und Operational-Ursprung, Änderungsakteur, Freigabe, NACM-Entscheidung und Integrität ruhender Daten getrennt festhalten.

Zur Laufzeit den Verbraucher auf exakte Bytes auflösen und Peer, Sitzung, Pfad, Zeit, Namen, Zweck, Algorithmus, Sperrprüfung, Verifikationsgrund und Autorisierung hinzufügen. Zentraländerungen verlangen eine Verbraucherfolgeanalyse; Ablaufmeldungen bleiben bis zur bestätigten Nutzung offen.

So bleibt RFC 9641 eine minimale gemeinsame Sprache für autonome Systeme. Das Modell koordiniert Vertrauensmaterial. Der laufende Verbraucher entscheidet. Der Beleg verhindert, dass der Schutz eines Managementpfads zur unbegrenzten Sicherheitsbehauptung wird.

Quellen