Zusammenfassung

  • ARIN erklärt, einzelne Aktionen ließen sich einzelnen API-Schlüsseln zuordnen; die aktuelle Anleitung beschreibt den sichtbaren Schlüsselbestand dennoch nur mit Präfix und Erstellungsdatum.
  • ACSP 2023.15 ist seit Oktober 2023 offen, obwohl ARIN damals den Nutzen einer frei wählbaren Beschreibung für Kunden mit mehreren Schlüsseln anerkannte.
  • Eine Beschreibung begrenzt keine Rechte, erzwingt keinen Ablauf und beweist keine Verwahrung. Sie hält den beabsichtigten Zweck fest, damit er gegen beobachtete Nutzung geprüft werden kann.
  • Aus dem Feld sollte ein versionierter Zwecknachweis werden, der nicht geheime Kennung, ausstellendes Konto, Aktivitätsklasse, Prüfverantwortung und Deaktivierungsbeleg verbindet.

Das Inventar erkennt den Schlüssel, nicht seine Aufgabe

Die richtige Sicherheitsentscheidung steht in ARINs Anleitung zuerst: Der vollständige API-Schlüssel wird nur bei seiner Erzeugung angezeigt. Danach soll das Geheimnis nicht erneut auf dem Bildschirm erscheinen. Unmittelbar damit verbunden ist jedoch eine andere Designentscheidung. In der Verwaltungstabelle, so der Text, lässt sich der Schlüssel anschließend nur noch anhand seines Key Prefix und des Erstellungsdatums identifizieren.

Geheimhaltung und Bedeutungsverlust sind nicht dasselbe. Das Präfix zeigt zuverlässig auf einen Eintrag. Das Datum verrät dessen Beginn. Keines von beiden erklärt, ob die Berechtigung für Reg-RWS, Änderungen an Netzressourcen, RPKI, IRR, DNSSEC, Reverse DNS oder einen eingeschränkten Bericht erzeugt wurde. Genau diese Einsatzfelder zählt ARIN selbst auf.

Die Anleitung sagt zudem, dass derselbe Schlüssel mehrere Interaktionen bedienen kann und dass Kunden mehrere Schlüssel anlegen können, um unterschiedliche Vorgänge zu verfolgen. Ein Schlüssel läuft nicht automatisch ab; er kann deaktiviert werden. Damit entsteht eine Kombination, die besonders viel Kontext verlangt: weitreichende Einsatzmöglichkeiten, potenziell mehrere Zugangsdaten und eine grundsätzlich unbefristete Lebensdauer.

Fehlt der Zweck bei ARIN, muss er anderswo aufbewahrt werden. Vielleicht trägt das Secret-Management-System einen guten Namen. Vielleicht steht das Präfix in einem Repository, einem Änderungsantrag oder einer Betriebsanweisung. Vielleicht kennt das Team die Zuordnung auswendig. Jedes dieser Modelle kann funktionieren, solange die externe Bezeichnung dauerhaft mit der Kennung verbunden bleibt, die ARIN akzeptiert. Nach Personalwechseln, Systemumbenennungen und Vault-Migrationen wird genau diese Verbindung jedoch zur Suchaufgabe.

Die Community hat die Lücke präzise benannt. Am 25. Oktober 2023 verlangte ACSP 2023.15 eine vom Nutzer festgelegte Beschreibung für API-Schlüssel. Der Einreicher erwähnte fehlende feingranulare Berechtigungen und benannte Dienstrollen, setzte sie aber nicht mit einer Beschreibung gleich. Ein Textfeld dokumentiert die vorgesehene Funktion; eine Zugriffskontrolle beschränkt die tatsächlich zulässigen Aktionen.

ARIN antwortete am 27. Oktober, die Möglichkeit sei für Kunden mit mehreren Schlüsseln nützlich. Sie solle in den Bereitstellungsplan aufgenommen und zusammen mit anderen Entwicklungsaufgaben priorisiert werden. Bis zur Umsetzung bleibe der Vorschlag offen. Sowohl die Seite des Vorschlags als auch der gegenwärtige ACSP-Index zeigen weiterhin Open, ohne späteren öffentlichen Tracking-Eintrag.

Daraus folgt nicht, dass ARIN intern nichts plant oder dass keine nicht öffentliche Oberfläche ein weiteres Feld besitzt. Belegt ist die engere Feststellung: Das öffentliche Versprechen hat keine öffentliche Erledigung erhalten, und die aktuelle öffentliche Anleitung endet noch immer bei Präfix und Datum.

Eine Spur zeigt das Geschehen, nicht den Auftrag

ARINs eigener Beitrag zur Schlüsselverwaltung in Teams beschreibt die Bedeutung eindeutiger Zugangsdaten. Wer einen persönlichen Schlüssel teilt, überträgt breite Kontrolle und zerstört die Unterscheidbarkeit der handelnden Personen. ARIN empfiehlt deshalb Role POCs und individuelle Schlüssel. Ein Schlüssel habe die Rechte des ARIN-Online-Nutzers, der ihn erzeugt hat; konkrete Aktionen ließen sich auf konkrete Schlüssel zurückführen.

Das ist eine brauchbare Aktivitätsspur. Ihr fehlt jedoch die Soll-Aussage.

Angenommen, ein vor zwei Jahren angelegter Schlüssel hat gestern ein IRR-Objekt verändert. Das Protokoll kann Kennung und Zeitpunkt liefern, vielleicht auch das authentifizierte Konto. Ob die Änderung erwartbar war, lässt sich erst beurteilen, wenn der ursprüngliche Auftrag bekannt ist. War der Schlüssel für IRR-Pflege vorgesehen? War er ein Berichtsschlüssel, dessen Nutzung später ausgeweitet wurde? Stammt er aus einer längst beendeten Migration? Ohne vorher festgehaltenen Zweck entsteht jede Erklärung im Nachhinein.

Eine Zweckbeschreibung liefert diese vorherige Aussage. „RPKI-Veröffentlichung primär“, „monatlicher WhoWas-Abruf“ oder „Reverse-DNS-Migration bis zur Ablösung“ lassen sich mit einer beobachteten Dienst- oder Aktionsklasse vergleichen. Der Text ist dadurch nicht automatisch wahr. Er kann veralten, zu allgemein sein oder nachträglich angepasst werden. Deshalb gehören Versionen und Aktivität zusammen.

Auch eine Abweichung ist kein automatisches Fehlverhalten. Ein lange ungenutzter Schlüssel kann vergessen oder für Notfälle reserviert sein. Ein Zugriff außerhalb der beschriebenen Funktion kann Missbrauch oder eine genehmigte Aufgabenerweiterung sein. Der Unterschied löst eine Prüfung aus; er beweist keinen Sicherheitsvorfall.

Diese Grenze muss die Oberfläche ausdrücklich wahren. Die Bezeichnung „nur lesen“ entzieht keine Schreibrechte, wenn das erzeugende Konto sie besitzt. „Läuft im Juni ab“ macht das Geheimnis im Juni nicht ungültig. „IRR“ verhindert keinen anderen zulässigen Aufruf. Würde ARIN aus einem Freitext ein Sicherheitsabzeichen machen, entstünde eine Kontrolle, die technisch nicht existiert.

Andere ACSP-Verfahren zeigen die Trennung. ACSP 2011.17 fordert Einschränkungen je Aktion und POC; ARIN veröffentlichte dazu eine erhebliche Kosten- und Komplexitätsschätzung. ACSP 2024.1 behandelt MFA, Quellnetz-Bindung oder Laufzeit. Die Konsultation 2024.3 befasste sich mit der Übertragung im Header und IP-Bereichen. Diese Maßnahmen verändern die Macht oder Exposition eines Schlüssels. Eine Beschreibung verändert die Nachweislage, auf deren Grundlage über diese Macht entschieden wird.

Die Nachbarbaustellen wurden inzwischen fertig

Am 28. Juli 2026 lieferte ARIN zwei angrenzende Verbesserungen aus. API-Token können seither vorzugsweise im Authorization-Header statt als URL-Parameter übertragen werden. Außerdem fiel die Sperre bei der Kontoerstellung, die nicht menschliche Servicekonten ausgeschlossen hatte. Die Softwareübersicht dokumentiert beide Änderungen und die zugehörigen Vorschläge wurden geschlossen. Der aktuelle Reg-RWS-Schnellstart kennzeichnet den Header als empfohlen und die URL-Variante weiterhin als unterstützt.

Der Header verringert die Wahrscheinlichkeit, dass ein Geheimnis unbeabsichtigt in URL-Verläufen, Proxy-Protokollen oder anderen Zwischenstellen auftaucht. Ein Servicekonto ermöglicht eine dauerhafte Maschinenidentität, ohne sie als dauerhaft beschäftigten Menschen auszugeben. Beides sind substanzielle Fortschritte.

Keine der beiden Änderungen erklärt den Zweck des einzelnen Schlüssels. Der Transportweg beantwortet, wo das Geheimnis in einer Anfrage liegt. Das Servicekonto beantwortet, welcher Principal sich authentifiziert. Ein Role POC trägt zur Berechtigungsgrundlage bei. Erst die Zweckangabe sagt, welche Automatisierung die Berechtigung ausüben sollte.

Ein Servicekonto kann drei Schlüssel besitzen: einen für RPKI, einen für Berichtsexporte und einen für eine befristete Umstellung. Ist der Principal sauber bezeichnet, aber bestehen die drei Zeilen nur aus Präfix und Datum, ist die Identitätsschicht gelöst und die Aufgabentrennung auf Zugangsdatenebene weiterhin ausgelagert.

Die Veröffentlichung vom Juli zeigt zugleich, wie sich eine Umsetzung überprüfbar abschließen lässt: Datum, konkrete Funktion, aktualisierte Anleitung und ACSP-Erledigung. Für 2023.15 sollte eine spätere Disposition entsprechend erklären, wo die Beschreibung eingegeben und angezeigt wird, wer sie ändern darf, ob Suche und Export möglich sind, ob Versionen erhalten bleiben und welche Kennung im Aktivitätsnachweis erscheint.

Ein einzelnes Freitextfeld wäre ein Anfang. Ohne Historie kann eine spätere Umbenennung den ursprünglichen Auftrag auslöschen. Ohne Export müssen große Organisationen das Inventar manuell übertragen. Ohne gemeinsame Kennung lassen sich Beschreibung und Aktion nicht sicher zusammenführen. Der eigentliche Gegenstand ist daher kein hübscheres Tabellenfeld, sondern ein kleiner Lebenszyklusnachweis.

Der Zwecknachweis

ARIN muss weder interne Hostnamen noch Repository-Pfade oder Bereitschaftspläne speichern. Solche Details können beim Kunden verbleiben. Notwendig ist ein stabiler, nicht geheimer Bezugspunkt zwischen dem von ARIN akzeptierten Schlüssel und dem vom Kunden erklärten Auftrag.

Ein zweckmäßiger Nachweis enthält mindestens:

  1. Präfix oder eine unveränderliche, nicht geheime Schlüsselkennung;
  2. eine Pflichtbeschreibung für neue Schlüssel und optionale strukturierte Tags wie Reg-RWS, RPKI, IRR, DNSSEC, Reverse DNS oder Berichte;
  3. den ausstellenden menschlichen oder technischen Principal sowie Organisation und POC-Kontext der Berechtigung;
  4. Erstellungszeit, letzte Nutzung und zuletzt beobachtete Dienst- oder Aktionsklasse, soweit ARIN dies sicher anzeigen kann;
  5. die für die nächste Prüfung verantwortliche Rolle und einen vom Kunden gesetzten Prüftermin;
  6. eine Historie der Zweckänderungen mit Akteur und Zeitpunkt;
  7. Zeitpunkt, Grund und Bestätigung der Deaktivierung; und
  8. den ausdrücklichen Hinweis, dass die Beschreibung weder Rechte erteilt noch entzieht oder beschränkt.

Die letzte Nutzung ist kein Automatismus zum Löschen alter Schlüssel. Sie macht aus einer Vermutung eine datierte Frage. Ein Schlüssel „monatlicher Bericht“, der seit achtzehn Monaten nichts abgerufen hat, braucht eine Erklärung. Ein Notfallschlüssel kann gerade wegen seiner Ruhe korrekt sein. Eine grobe Aktionsklasse reicht häufig aus, um Unterschiede sichtbar zu machen, ohne jede betroffene Ressource offenzulegen.

Die Versionierung schützt die Vergangenheit vor der Gegenwart. Ein Migrationsschlüssel kann in einen Dauerbetrieb hineinwachsen. Die Organisation kann eine neue Zugangsdaten ausstellen oder die geänderte Aufgabe ausdrücklich genehmigen. In beiden Fällen darf „Migration“ nicht spurlos durch „Produktion“ ersetzt werden. Sonst verschwindet, wann und durch wen der Auftrag erweitert wurde.

Auch die Deaktivierung braucht einen Abschlussbeleg. ARIN bietet die Aktion bereits an. Der Nachweis sollte dokumentieren, wann die Annahme des Schlüssels endete und welcher Auftrag damit stillgelegt wurde. Er belegt nicht, dass jede Kopie des Geheimnisses gelöscht ist. Er liefert aber das Ereignis, das der Kunde mit der Entfernung aus Vault, Software und Betriebsablauf abgleichen kann.

ARIN könnte sich auch bewusst gegen interne Zweckdetails entscheiden. Dann wäre ein konsistentes externes Modell möglich: unveränderliche Kennung in der ARIN-Tabelle, vollständiger Aktivitätsexport mit derselben Kennung, Zweck und interne Verantwortung im System des Kunden. Eine ausgelagerte Verantwortung ohne verlässlichen Join-Key wäre dagegen keine saubere Grenze, sondern ein Bruch im Nachweis.

Verbesserung ohne erfundenen Schaden

Die Quellen enthalten keine Zahl verwaister oder überflüssiger ARIN-Schlüssel. Sie messen nicht, wie viele Kunden mehrere Schlüssel betreiben oder eine Deaktivierung aus Unsicherheit verschoben haben. Sie dokumentieren keinen durch eine fehlende Beschreibung verursachten Angriff, Missbrauch oder Ausfall. Solche Ereignisse dürfen nicht unterstellt werden.

Die institutionelle Frage ergibt sich aus den dokumentierten Eigenschaften. Schlüssel können unbefristet bestehen, verschiedene Dienste bedienen und Aktionen hinterlassen, die ihnen zugeordnet werden. Das öffentlich beschriebene Inventar hält ihren Zweck nicht fest. Bei Übergabe, Audit oder Stilllegung trägt der Kunde die Kosten, die ursprüngliche Absicht wiederherzustellen.

Die relevante Frage lautet deshalb nicht, ob eine Beschreibung einen Angreifer stoppt. Das tut sie nicht. Sie lautet, ob die Institution, die automatisierte Autorität über Ressourcendaten akzeptiert, zugleich die Erklärung erhalten sollte, mit der diese Autorität später geprüft werden kann. Ein funktionierender Schlüssel ist noch kein begründeter Schlüssel.

Quellen