Zusammenfassung

  • Seit dem 28. Juli 2026 akzeptiert ARIN nichtmenschliche Dienstkonten und empfiehlt für REST-Aufrufe den API-Token im Authorization-Header. URL-Parameter bleiben möglich.
  • Zwei 2022 eingereichte Vorschläge wurden nach dem Start geschlossen: einer für Maschinenkonten, einer gegen API-Schlüssel in protokollierten URLs.

Eine URL zeigt, wohin ein Aufruf geht. Sie ist kein Tresor. Systeme protokollieren häufig die vollständige Adresse. Steht der API-Schlüssel als Abfrageparameter darin, wandert das Geheimnis gleich mit in die Logs.

ARIN Online unterstützt seit dem 28. Juli eine bevorzugte Alternative: Authorization: ApiKey <API_KEY>. Der Token steht dann im HTTP-Header und nicht in der URL. Die bisherige Methode funktioniert weiter. Der konkrete Gewinn: Ein Schlüssel muss nicht mehr in dem Teil des Aufrufs stehen, den Protokolle gewöhnlich vollständig speichern.

Vorschlag 2022.5 hatte das am 11. Februar 2022 gefordert. Die Einreichung verwies darauf, dass URL-Protokolle API-Tokens für Personen sichtbar machen können, die sie für ihre Arbeit nicht brauchen. ARIN hielt den Header für die beste Alternative und nahm die Änderung in die Entwicklungsplanung auf. Am 29. Juli 2026 wurde der Vorschlag geschlossen, einen Tag nach der Freigabe.

Im selben Release fiel eine zweite Schranke: Bei der Kontoerstellung sind nichtmenschliche Dienstkonten nun zugelassen. Vorschlag 2022.11 hatte sie für programmatische REST-Integrationen verlangt. ARINs ursprüngliche Sorge betraf die Zuordnung: Die Organisation wollte erkennen können, wer Änderungen über die API vorgenommen hatte. Im April 2022 erkannte ARIN den Nutzen von Rollen- und Dienstkonten an und hielt die technische Arbeit für überschaubar. Die Umsetzung kam gut vier Jahre später.

Ein Dienstkonto bezeichnet den automatisierten Akteur; der Header verlegt das Geheimnis. Für Änderungen gilt weiterhin ARINs bestehende Autorisierung: Laut Reg-RWS-Kurzanleitung muss das ARIN-Online-Konto mit einem Point of Contact verknüpft sein, der die betreffende Organisation und den Datensatz verwalten darf. Der API-Schlüssel authentifiziert den Aufruf, der POC liefert die erforderliche Befugnis.

Auch die Lebensdauer des Schlüssels ist klar geregelt. Er verfällt nicht automatisch, kann jederzeit deaktiviert werden und wird nur bei der Erstellung vollständig angezeigt. Mehrere Schlüssel helfen, einzelne Anfragen oder Berichtszugriffe nachzuverfolgen. Eine ARIN-Konsultation von 2024 behandelte Header und IP-Bereichsgrenzen gemeinsam. ARIN ordnete die Header-Option ein und stellte IP-Begrenzungen in eine eigene Prüf- und Planungsphase. Das Release von 2026 meldet den Header; die beiden Änderungen haben getrennte Wege.

Die Maschine bekommt endlich einen eigenen Ausweis, und der Schlüssel muss nicht mehr auf der URL mitfahren. Betreiber müssen jedem Dienstkonto ein verantwortliches Team zuordnen und festlegen, wer dessen Schlüssel abschalten darf.

Quellen