Zusammenfassung

  • Der finale NIST-Bericht IR 8625 behandelt die Sicherheit des RAN Intelligent Controller (RIC). NIST stellte ihn am 8. Oktober zusammen mit einem gesonderten Entwurf für O-RAN-Einsätze von Bundesbehörden vor.
  • O-RAN nutzt gegenseitiges TLS zur Authentifizierung von Komponenten und OAuth2 zur Autorisierung. Die O-RAN ALLIANCE legt jedoch weder das Format noch die Granularität der OAuth2-Scopes fest. Betreiber entscheiden, ob eine Berechtigung für ein Asset, eine API oder eine einzelne Aktion gilt.
  • Ein zentraler Entscheidungspunkt erleichtert Änderungen an Richtlinien, macht Autorisierungsanfragen aber von diesem Dienst abhängig und erschwert unter Umständen den Zugriff von Anwendungen aus einer anderen Verwaltungsdomäne.

Kann eine xApp eine Richtlinie des Funknetzes lesen, ohne sie ändern oder löschen zu dürfen? NISTs finaler Sicherheitsbericht nutzt diese Abgrenzung als Beispiel für OAuth2-Scopes und überlässt den Detaillierungsgrad der Organisation, die das Netz betreibt.

Am 8. Oktober veröffentlichte NIST zwei O-RAN-Dokumente mit unterschiedlichen Aufgaben. Der finale IR 8625 untersucht Sicherheitsanforderungen des Near-Real-Time-RAN-Intelligent-Controller und seiner Anwendungen. IR 8623 ist dagegen ein separater Entwurf für ein Profil von Bundesbehörden. Hier geht es nicht erneut um die institutionelle Risikofrage dieses Entwurfs, sondern darum, wer innerhalb eines programmierbaren Funknetzes festlegt, welche Aktionen eine Anwendung ausführen darf.

Der RIC bietet Anwendungen einen Rahmen, um Ressourcen des Funkzugangsnetzes zu überwachen und zu steuern. Laut NIST arbeitet der Near-RT RIC auf einer Teilmenge der Funkzellen mit betrieblichen Reaktionszeiten unter einer Sekunde. Der Non-RT RIC erfasst weiter gefasste Daten und steuert langsamer. xApps laufen auf der Near-RT-Seite, rApps auf der Non-RT-Seite. Eine rApp kann Messwerte mehrerer Zellen analysieren und den xApps eine Richtlinie oder Konfigurationsregel für eine zeitkritische Anpassung übermitteln.

Die zusätzliche Flexibilität gibt Software auch Einfluss auf das Verhalten des Netzes. NIST weist in seiner Bedrohungsanalyse darauf hin, dass Drittanbieter-Apps RAN-Daten sammeln und an andere Komponenten weitergeben können, auch außerhalb des RAN. Gefälschte Identitäten, zu weitreichende Rechte, manipulierte Daten oder eine Fehlkonfiguration können deshalb über den einzelnen App-Prozess hinauswirken. Das sind Bedrohungskategorien, keine gemeldeten Angriffe oder Befunde zu einem bestimmten Betreiber.

Der Bericht beschreibt gegenseitiges TLS mit X.509-Zertifikaten zur Authentifizierung und OAuth2-Zugriffstoken zur Autorisierung. Der Scope eines Tokens enthält Berechtigungen für eine Ressource; die Ressource selbst oder ein Policy Enforcement Point prüft, ob die angeforderte Aktion zulässig ist. Anfragende, Ressource und Autorisierungsserver müssen die Bedeutung des Scopes gemeinsam verstehen. Die O-RAN ALLIANCE schreibt dessen Format derzeit jedoch nicht vor. NISTs Beispiele reichen vom Zugriff auf ein ganzes Asset über eine bestimmte API bis zum einzelnen Aufruf: etwa eine Richtlinie lesen, aber nicht erstellen oder löschen.

Die Organisation, die das Netz bereitstellt, wählt die Granularität nach ihrer Zero-Trust-Politik und ihrem Betriebsreifegrad. Das hat Folgen. Eine breite Berechtigung vereinfacht die Integration einer App, kann ihr aber auch Aktionen erlauben, die sie für ihre Aufgabe nicht braucht. Feingranulare Rechte begrenzen mögliche Aktionen, setzen jedoch voraus, dass Anfragende, Ressource und Autorisierungsdienst Begriffe, Zuständigkeit und Lebenszyklus abstimmen. Der Bericht behauptet weder, dass alle Betreiber dasselbe Modell verwenden, noch zertifiziert er eine konkrete Umsetzung.

In cloudnativen Umgebungen können Plattformkomponenten wie ein Service Mesh Authentifizierung und Autorisierung übernehmen, statt sie in der Geschäftslogik jeder App umzusetzen. Das kann Kontrollen vereinheitlichen. NIST beschreibt auch einen zentralen Policy Decision Point: Er vereinfacht Richtlinienänderungen und bündelt Informationen über Zugriffe und Sicherheitslage. Der Zielkonflikt ist ausdrücklich benannt. Fällt der Punkt aus, lassen sich Zugriffsanfragen im RAN über ihn nicht autorisieren. Daraus folgt nicht, dass der Funkdienst selbst ausfällt; der Bericht beschreibt eine Abhängigkeit der Autorisierung, keinen Netzausfall.

Schwieriger wird die Grenze, wenn eine App zu einer anderen Verwaltungsdomäne gehört. NIST nennt eine als Software-as-a-Service angebotene rApp als Beispiel. Der zentrale Entscheidungspunkt eines Betreibers verfügt möglicherweise nicht über alle Informationen, um externe Akteure zu beurteilen. Ein Zugriffstoken enthält zudem nicht zwangsläufig alle Angaben zur aktuellen Sicherheitslage oder zum Verhalten des Anfragenden. Wer die Identität einer App bestätigt, wer ihre Scopes ändern darf und welche Stelle die Entscheidungsgrundlage einsehen kann, muss im Betrieb geklärt werden.

NIST unterscheidet außerdem Kanalschutz und Datenschutz auf Objektebene. Gegenseitiges TLS schützt die Verbindung zwischen Komponenten. In cloudnativen Abläufen kann ein gemeinsamer Speicher oder Nachrichtenbroker zwischen dem Erzeuger und dem späteren Nutzer einer Richtlinie oder Messung liegen. Signaturen oder Verschlüsselung am Datenobjekt können Herkunft, Integrität oder Vertraulichkeit über solche Zwischenstationen hinweg schützen. Dafür müssen Erzeuger und Empfänger Schlüssel verwalten und Artefakte prüfen. IR 8625 nennt dies als weiteren Prüfbereich, nicht als Pflicht, den Kanalschutz zu ersetzen.

Die Schlussfolgerung des Berichts bleibt begrenzt: Standardisierte Protokolle ermöglichen Zero-Trust-Kontrollen, bestimmen aber nicht, was die vom Betreiber vergebenen Rechte bedeuten. Auch die Verantwortung für durchgängige Autorisierung und Vertrauen über Domänengrenzen hinweg bleibt bestehen. Die Quellen nennen keine konkrete Implementierung, keinen Einbruch, keinen Richtlinienausfall und keine gemessenen Auswirkungen auf die Verfügbarkeit.

Quellen