Zusammenfassung

  • AFRINICs Jahresbericht 2025 nennt eine kleinere physische Rechenzentrumsfläche und mehr Cloud- und Hybridnutzung sowie modernes Bacula, vollständige Backup-Abdeckung kritischer Dienste, externe Kopien in AWS S3, vierteljährliche Restore-Tests und Ansible-Automatisierung.
  • Diese Maßnahmen sind Fortschritte, aber keine austauschbaren Belege: abgeschlossener Job, lesbares Objekt, wiederhergestellter Snapshot, gestartete Anwendung und erfolgreiche Mitgliederaktion bilden getrennte Zustände.
  • Eine nicht sensible öffentliche Kontrollkarte könnte je Dienst Ziele, Szenario, Integritäts- und Abnahmetests, Lieferantenstufen, Ausnahmen und die jüngste Übung in einer unabhängig kontrollierten Umgebung ausweisen.

Der überzeugende Teil der Verkleinerung

AFRINICs Bericht beschreibt keinen ungeordneten Rückzug aus eigener Infrastruktur. Ausgemusterte und veraltete Geräte wurden entfernt, fehlerhafte Netzwerk- und Speicherkomponenten ersetzt, 10-Gbit/s-Peering-Technik installiert, Backup-Speicher erweitert und redundante Routing- und Uplink-Entwürfe vorbereitet. Genannt werden Arbeiten in Mauritius, Johannesburg, Parklands, Mombasa und Isando. Bei einzelnen Vorhaben blieben Lieferantenfristen und Genehmigungen maßgeblich.

Eine kleinere eigene Fläche kann dabei vernünftig sein. Alte Hardware ist nicht automatisch Kontrolle; oft ist sie nur ein bekannter Ausfall mit steigenden Wartungskosten. Externe Kopien schützen vor einem lokalen physischen Ereignis. Cloud-Ressourcen lassen sich für einen Wiederanlauf möglicherweise schneller bereitstellen als ein Ersatzstandort. Bacula und Ansible können aus Erfahrungswissen einen reproduzierbaren Ablauf machen. Vierteljährliche Wiederherstellungstests sind aussagekräftiger als die bloße Meldung, dass Backups geschrieben wurden.

Gerade weil diese Vorteile real sind, sollte die Beweisführung präziser werden. Weniger eigene Racks bedeuten nicht zwingend weniger Abhängigkeiten. Kontrolle verteilt sich auf Konten, Rollen, Regionen, Schlüssel, Restore-Regeln, Verträge und Freigabewarteschlangen. Keine dieser Abhängigkeiten ist für sich ein Mangel. Sie bestimmt aber, welche Störung ein Test tatsächlich abdeckt.

Der Bericht nennt die vollständige Sicherung kritischer Dienste und S3 als externes Ziel. Nicht veröffentlicht sind die Zuordnung von Diensten zu Datenklassen, RPO und RTO, getestete Snapshots, Speicherregion, Konto- und Schlüsselverantwortung, Zielumgebung, wiederhergestellte Softwareversion, Einzelprüfungen oder eine Übung außerhalb der üblichen Lieferantenumgebung. Daraus folgt kein negatives Urteil. Es markiert den Raum für einen kontrollierten öffentlichen Nachweis.

Neun Stufen statt eines grünen Häkchens

Erstens kann ein Backup-Job abgeschlossen sein. Zweitens kann das gespeicherte Objekt lesbar sein. Drittens kann ein ausgewählter Snapshot an einem Ziel wiederhergestellt werden. Viertens können Schema, Signaturen und referenzielle Integrität bestehen. Fünftens startet die Anwendung. Sechstens antwortet ihr Endpunkt. Siebtens gelingt einem Mitglied oder einer vertrauenden Stelle die entscheidende Handlung. Achtens werden Wiederherstellungspunkt und -zeit eingehalten. Neuntens lässt sich derselbe maßgebliche Zustand in einer unabhängig kontrollierten Umgebung rekonstruieren.

Jede Stufe ist wertvoll, keine beweist automatisch die folgende. Ein gestarteter Datenbankprozess kann eine unpassende Version enthalten. Eine antwortende Webseite kann keine authentifizierte Ressourcenhandlung zulassen. Vollständige Bytes können semantisch unbrauchbar sein. Ein technisch erfolgreicher Lauf kann das zugesagte Zeitfenster verfehlen. Und ein Test im normalen Konto belegt nicht, dass der Dienst ohne dieses Konto zurückkehrt.

Für ein regionales Internetregister ist die Unterscheidung besonders wichtig. WHOIS, MyAFRINIC, DNS und RPKI transportieren nicht nur Verfügbarkeit, sondern Autorität und Abhängigkeiten für Dritte. Der Prüfpunkt muss deshalb die fachliche Handlung umfassen. Ein Infrastrukturmonitor allein kann nicht entscheiden, ob die wiederhergestellte Aussage weiterhin gültig und verwendbar ist.

Das lässt sich veröffentlichen, ohne einen Angriffsplan offenzulegen. Kontrollklassen, Zieltypen und Ergebnisarten benötigen keine Kontonamen, Bucket-Bezeichnungen, Schlüssel, Standortdetails oder Notfallbefehle. Transparenz betrifft hier die Qualität des Nachweises, nicht die Mechanik des Zugangs.

Die Drittgrenze steht schon im Leistungsversprechen

AFRINICs öffentliches Service Level Commitment trägt die Kennzeichnung Version 1, November 2015. Es umfasst Registrierung und Kundenservice, Datenbanken und öffentliche Online-Dienste, Reverse DNS, Abrechnung und Infrastruktur. WHOIS, MyAFRINIC, Websites, IRR, DNS, DNSSEC, Mail und RPKI werden ausdrücklich genannt. Zugesagt sind 99,8 Prozent Verfügbarkeit je Dienst und für das Netzwerk.

Ausfälle von Drittanbietern sind aus der Berechnung ausgenommen. AFRINIC erklärt außerdem, für solche Anbieter keine Leistungszusage geben zu können, die eigene Verpflichtung aber in Geschäftsbeziehungen für Kerndienste abbilden zu wollen. Das ist kein Beleg für ein Lieferantenversagen. Es ist eine veröffentlichte Messgrenze.

Wenn eine Wiederherstellung auf eine externe Genehmigung wartet, erlebt das Mitglied trotzdem die gesamte Unterbrechung. Ein Vertrag darf Zuständigkeit teilen; eine öffentliche RTO-Messung sollte die Uhr deshalb nicht verschwinden lassen. Dass der Jahresbericht bereits von lieferantenabhängigen Zeitplänen spricht, macht eine Zuordnung der Wartezeit sinnvoll, bevor ein Vorfall eintritt.

AFRINIC berichtet zugleich, kritische Dienste hätten 2025 typischerweise über 99,7 Prozent Verfügbarkeit erreicht. Zum Erhebungszeitpunkt zeigte die Statusseite WHOIS Database, MyAFRINIC Portal, AFRINIC Web Sites, Mailing Lists, New Member Registration Portal, DNS Services, RPKI Systems und Other Systems als Operational; für die Wurzelkomponenten war keine Metrikzusammenfassung angegeben. Jahreswert, aktueller Zustand und Wiederanlauftest sind unterschiedliche Beobachtungen. Keine ersetzt die andere.

S3 macht Bedingungen sichtbar

AWS beschreibt für S3 eine geteilte Verantwortung. AWS betreibt die Infrastrukturschicht des verwalteten Dienstes. Der Kunde bleibt für die Resilienz seiner Daten verantwortlich, darunter Entscheidungen über Backup, Versionierung und Replikation.

Dokumentierte Möglichkeiten umfassen kontinuierliche oder periodische Sicherungen, zeitpunktbezogene Wiederherstellung und direkten Datenzugriff. Der AWS-Backup-Weg für S3 setzt S3 Versioning voraus. Rollen und Berechtigungen, ACL-Verhalten, Versionierung am Ziel, Region und Verfügbarkeit von Verschlüsselungsschlüsseln können das Resultat verändern. Objekte können übersprungen werden, wenn Name oder Versionskennung bereits vorhanden sind. Eine Wiederherstellung in den ursprünglichen Bucket überschreibt nicht pauschal alles Bestehende.

Das sagt nicht, dass AFRINIC AWS Backup, Versioning, Replication, regionsübergreifende Kopien, eine bestimmte Region oder ein bestimmtes IAM- und Schlüsselmodell verwendet. Es sagt nur: Der Ausdruck „S3 erfolgreich wiederhergestellt“ braucht einen Kontext. Objektlesbarkeit, Anwendungsrekonstruktion, fachliche Abnahme und unabhängiger Ausstieg sind vier verschiedene Tests.

Eine kleine Karte mit großen Unterschieden

Eine öffentliche Dienst-zu-Recovery-Karte könnte pro Komponente die maßgebliche Datenklasse, RPO und RTO, eine nicht sensible Übungskennung, Bezugszeit, Integritäts-Hash und Aufbewahrungsklasse enthalten. Danach würde sie AFRINIC-kontrollierte und lieferantenkontrollierte Phasen trennen.

Szenario und Zielklasse würden zeigen, ob Konto-, Regions- oder Anbietergrenzen überschritten wurden. Berechtigungen und Schlüssel erschienen nur als Verwahrungsklassen. Die Ergebnisse würden Vollständigkeit, Schema, Signatur, Referenzen, Anwendungsstart, öffentliche Antwort und Nutzerabnahme einzeln ausweisen. Start, technische Nutzbarkeit und fachliche Abnahme bekämen eigene Zeiten.

Übersprungene Objekte, offene Genehmigungen, Verantwortliche, Fristen und Korrekturwege gehören ebenfalls hinein. Die letzte Übung in einer unabhängigen Umgebung bildet den Abschluss. Eine vertragliche Exportoption ist keine geübte Wiederherstellungsfähigkeit.

Eine solche Karte ist kein Ersatz für Prüfung und kann veralten. Sie schafft aber eine konstante Sprache. Ein dokumentierter Fehler mit Abhilfe kann Vertrauen stärken; ein jedes Quartal anders definiertes „bestanden“ kann es nicht.

Was nicht behauptet werden kann

Die geprüften Quellen belegen keinen Ausfall, fehlgeschlagenen Restore, fehlendes Backup, Sicherheitsvorfall oder Datenverlust bei AFRINIC. Sie zeigen nicht, dass S3 sämtliche kritischen Dienste oder alle Registerdaten enthält. Sie belegen weder Lieferantenverzug noch aktuelle Bindung, Unfähigkeit zum AWS-Ausstieg oder Unrichtigkeit des 99,7-Prozent-Werts. Die Statusseite ist kein historisches Archiv, doch ihre Gegenwartsangaben sind deshalb nicht falsch.

Der Vorschlag ist vorsorglich. AFRINIC hat starke Bausteine veröffentlicht: weniger alte Technik, externe Kopien, moderne Werkzeuge, Automatisierung und regelmäßige Tests. Nun sollte es den letzten Schritt definieren. Eine kleinere Fläche ist dann nicht nur effizienter, sondern auch nachweisbarer.

Quellen