Zusammenfassung

  • Das BTW-Verzeichnis nennt das Unternehmen vollständig als Keltree Pty Ltd as trustee for The Kelly Family Trust T/A IBC Digital. Auch das Mitgliederverzeichnis von APNIC verbindet Keltree mit dem Handelsnamen IBC.[1][2] Whois und RDAP von APNIC verknüpfen diese Identität mit AS10078 und dem portablen IPv4-Präfix 203.24.93.0/24.[3][4][5] Diese Einträge belegen Kennungen, Status und dokumentierte Zuständigkeit. Sie zeigen nicht, wer jedes Gerät betreibt, wie ein privates Kundensystem aufgebaut ist oder ob ein Dienst über längere Zeit zuverlässig war.

  • In der für diese Recherche verwendeten Momentaufnahme des RIPE NCC waren keine direkt von AS10078 angekündigten Präfixe sichtbar. Gleichzeitig war 203.24.93.0/24 bei 328 von 328 abgefragten IPv4-Full-Table-Peers sichtbar; als beobachteter Ursprung erschien AS56035.[6][7][8] Dieser Unterschied ist kein Beleg für einen Ausfall. Registerzustand und laufende Route sind verschiedene Beweisebenen. Die zugehörige RPKI-Abfrage ergab unknown, nicht invalid.[9]

  • Die öffentlichen Seiten von IBC beschreiben gemanagtes und selbst verwaltetes Hosting, DNS, Überwachung, Backups, Patching, Staging, Systemintegration, Dokumentation und Support.[10][11][13][14][15][16][17][18] Die Hosting-Bedingungen verteilen außerdem Verantwortlichkeiten zwischen Anbieter und Kunde.[12] Damit ist ein Leistungsangebot und ein vorgesehenes Betriebsmodell belegt. Nicht belegt sind unabhängige Verfügbarkeitswerte, eine vollständige Störungshistorie oder das Produktionsergebnis eines benannten Kunden.

Bildkontext: Das verwendete Creative-Commons-Foto zeigt einen historischen Rechenzentrumsraum der Universität St. Gallen. Es dient ausschließlich als allgemeiner Kontext für physische Infrastruktur, Wartung und Betreiberkontinuität. Es zeigt weder IBC Digital noch Keltree Pty Ltd, AS10078, AS56035, eine IBC-Anlage, eine Kundeninstallation, einen Vorfall, gemessene Zuverlässigkeit oder ein Produktionsergebnis.[19]

Exakte Identität als technische Kontrolle

Der lange Unternehmensname ist keine bloße Formalität. Der BTW-Eintrag und das APNIC-Mitgliederverzeichnis bilden gemeinsam eine Evidenzkette zwischen Keltree als Trustee, dem Kelly Family Trust und dem Handelsnamen IBC Digital.[1][2] Verträge, Rechnungen, Internetressourcen und Abuse-Kontakte können unterschiedliche Namensformen verwenden. Ohne eine belastbare Zuordnung kann dieselbe Organisation fälschlich in mehrere Objekte zerlegt werden; umgekehrt können ähnlich klingende Marken ohne Beleg zusammengeführt werden.

Das Whois-Objekt für AS10078 trägt die Bezeichnung KPLATKFT-AS-AP und verweist auf Keltree und IBC.[3] RDAP führt das autonome System als aktiv und stellt administrative, technische und Abuse-Rollen strukturiert dar.[4] Ein weiteres RDAP-Objekt beschreibt 203.24.93.0/24 als aktiven portablen Adressraum, der derselben Identität zugeordnet ist.[5] Das Register ist hier ein Hauptbuch: Es wahrt die Eindeutigkeit der Ressource und dokumentiert Status, Kontakte und Verantwortungswege. Es ist nicht das laufende Netz.

Ein eigenes ASN oder ein portables Präfix bedeutet nicht, dass ein Unternehmen jeden Router, jede Verbindung und jedes Rechenzentrum unmittelbar betreibt. Ein autorisierter Upstream, ein Rechenzentrumsnetz oder ein Managed-Network-Partner kann eine Route ankündigen. Umgekehrt beseitigt die Nutzung fremder Infrastruktur nicht die Verantwortung des Dienstleisters gegenüber seinen Kunden. Entscheidend ist, wer eine Änderung genehmigen darf, wo diese Genehmigung festgehalten wird und ob externe Beobachtung dem freigegebenen Zustand entspricht.

Registerzustand und Routingzustand getrennt bewerten

Der Routing Information Service des RIPE NCC liefert eine zeitlich und methodisch begrenzte Außenbeobachtung. Dass bei AS10078 keine direkt angekündigten Präfixe sichtbar waren, bedeutet nur, dass die abgefragten Kollektoren zu diesem Zeitpunkt keine solchen Ankündigungen zeigten.[6][7] Daraus darf weder Stilllegung noch Störung, Reservenutzung oder eine bestimmte Lieferantenbeziehung abgeleitet werden. Die öffentlichen Quellen nennen den Grund nicht.

Das portable /24 zeigte einen anderen aktuellen Zustand. 203.24.93.0/24 war bei allen 328 abgefragten IPv4-Full-Table-Peers sichtbar, mit AS56035 als beobachtetem Ursprung.[8] Das belegt breite Sichtbarkeit in diesem Messfenster. Es belegt weder optimale Pfade noch die Korrektheit einer Anwendung, historische Stabilität oder Kundenzufriedenheit. BGP-Sichtbarkeit beantwortet eine andere Frage als ein erfolgreicher Login, eine Datenbanktransaktion oder die Wiederherstellung eines Dienstes.

Die unterschiedliche ASN-Zuordnung ist daher eine konkrete Abstimmungsaufgabe, keine Anschuldigung. Verantwortliche Betreiber sollten die aktuelle Autorisierung für AS56035 oder einen Nachfolger, die änderungsberechtigten Parteien, die Notfallkontakte und den Rücknahme- oder Migrationspfad kennen. Die öffentliche Evidenz sagt nicht, ob AS56035 als Upstream, Hosting-Partner oder in einer anderen autorisierten Rolle arbeitet. Die belastbare Aussage bleibt auf die beobachtete Abweichung zwischen Registeridentität und Routingursprung beschränkt.

RPKI verlangt die gleiche Genauigkeit. unknown bedeutet, dass für die abgefragte Kombination kein validierender ROA gefunden wurde, aber auch kein als ungültig bewerteter Konflikt vorlag.[9] Dies als „ungültige Route“ zu bezeichnen, wäre sachlich falsch. Ebenso falsch wäre die Behauptung, die Route sei kryptografisch abgesichert. Die betriebliche Aufgabe besteht darin, eine beabsichtigte ROA-Politik festzulegen, die Autorität zur Veröffentlichung zu sichern, Ursprung und maximale Präfixlänge zu bestimmen und jede Änderung extern zu prüfen.

DNS als eigene Kontroll- und Wiederherstellungsfläche

Zum Beobachtungszeitpunkt antwortete ibc.com.au mit der IPv4-Adresse 203.24.93.37. Als autoritative Nameserver erschienen ns1.ibc.com.au und ns2.ibc.com.au, während die Mailzustellung einen Microsoft-Schutzdienst einbezog.[5][8] Damit werden Verbindungen zwischen Domain, registriertem Adressraum, Web, DNS und E-Mail sichtbar. Nicht sichtbar werden sämtliche internen Ursprünge, Firewalls, Ersatzstandorte, Konten und Lieferantenverträge.

Zwei Nameservernamen beweisen keine unabhängigen Ausfallbereiche. Beide können dieselben Zugangsdaten, dieselbe Verwaltungsoberfläche, Software, Route oder Änderungsvorlage verwenden. Betreiber müssen Delegation und Antworten von mehreren Netzen aus prüfen und Registrarzugriff, Glue, Zonendaten, DNSSEC-Schlüssel bei dessen Einsatz sowie Wiederherstellungsbefugnisse getrennt dokumentieren.

Auch das Fehlen einer AAAA-Antwort in einer einzelnen Abfrage ist eine Beobachtung, keine abschließende Bewertung der IPv6-Fähigkeit. Es sagt, dass der abgefragte Name in diesem Moment keine IPv6-Adresse lieferte. Andere Dienste oder Planungen sind dadurch weder bestätigt noch ausgeschlossen. Verantwortungsvolle Analyse hält die Grenze der Messung fest und erfindet keine Strategie.

E-Mail erweitert die Abhängigkeiten. Eine Website kann erreichbar sein, während Mail ausfällt; ein funktionierender MX-Eintrag beweist wiederum nicht die Gesundheit der Webanwendung. Zur Wiederherstellung einer Domain können Registrar, DNS, Webhosting, Mail, Zertifikate und Netzlieferanten jeweils eigene Konten und Zuständigkeiten verlangen. Ein exportierbarer, geprüfter Zonenbestand ist deshalb ein Kontinuitätsgut, keine Komfortfunktion.

Was die Hosting-Unterlagen von IBC belegen

Die aktuelle Hosting-Seite von IBC beschreibt australisches Hosting für Websites, Anwendungen und mobile Middleware. Als Produktionsstandort wird NEXTDC P2 Perth genannt, als Backup- und Disaster-Recovery-Option NEXTDC P1 Malaga und als Staging- beziehungsweise Abnahmeumgebung bei aktivem Wartungsvertrag eine weitere Umgebung in Malaga.[10] Außerdem nennt die Seite Datenbanken, Suche, Caches, Überwachung, Backups, Zugriffskontrollen, TLS, Web Application Firewall, kontrollierte Releases und optionale Hochverfügbarkeit.[10]

Das sind Erklärungen des Anbieters zu seinen Fähigkeiten. Sie beweisen nicht, dass jeder Kunde jede Kontrolle bezieht, dass die Kontrolle in einem definierten Zeitraum lückenlos funktionierte oder dass ein konkreter Wiederanlauf ein Ziel erfüllte. Die Empfehlung eines 99,9-Prozent-Modells und die Möglichkeit, höhere Verfügbarkeit zu entwerfen, bleiben Leistungsbeschreibungen. Eine Option ist nicht mit einer gekauften, geprüften und gemessenen Implementierung gleichzusetzen.

Ein älteres Dokument zu Hosting-Plänen beschreibt Full-Service- und Self-Service-Modelle, virtuelle Server, DNS, Monitoring, Backup, Firewalls, physischen Zugang, redundante Anbieter und Umgebungssteuerung.[11] Da es 2018 erstellt wurde und andere Standortangaben als die aktuelle Seite enthält, ist es als historische Evidenz des Angebots zu lesen, nicht als aktuelles Inventar. Gerade der Unterschied macht die Wartungskosten sichtbar: Einrichtungen, Lieferanten und Produkte ändern sich; veraltete Dokumente müssen außer Kraft gesetzt und Runbooks, Verträge und Anlagenlisten abgeglichen werden.

Managed und Self-Managed verschieben die Verantwortung. In einem gemanagten Modell übernimmt der Anbieter mehr Konfiguration, Patching, Überwachung und Reaktion. In einem selbst verwalteten Modell trägt der Kunde mehr Anwendungs- und Kontenarbeit. Die gemeinsame Grenze bleibt in beiden Fällen bestehen. Der Kunde kontrolliert Inhalte, Geschäftsanforderungen und Benutzerrechte; der Anbieter kontrolliert Teile der Plattform; weitere Lieferanten kontrollieren Gebäude oder Netze. Verzögerungen entstehen häufig an dieser Grenze, auch wenn jede Partei ihren eng definierten Teil erfüllt.

Die Hosting-Bedingungen von 2022 behandeln Wartungsfenster, kundenseitig bereitgestellte Inhalte, Anwendungssicherheit, Schutzmaßnahmen in gemeinsam genutzten Systemen, Tests vor dem Betrieb, entfernte Verbindungen, Zugangscodes, Kündigung und Haftungsgrenzen.[12] Sie zeigen erwartete Ausnahmefälle und die Verteilung rechtlicher beziehungsweise wirtschaftlicher Risiken. Sie sagen nicht, wie oft Vorfälle eintreten. Ein Vertrag führt auch keine Wiederherstellung aus; dafür braucht es aktuelle Zugänge, eine befugte Person und eine erprobte Vorgehensweise.

Patching: Routine und Ausnahme sauber trennen

Die Seite zum Security Patch Management beschreibt eine tägliche Prüfung auf kritische Updates, die monatliche Anwendung in einer Testumgebung, Kundentests und eine geplante Produktionseinführung ungefähr eine Woche nach dem Test, sofern kein Hold verlangt wird.[13] Quellcodeverwaltung, getrennte Tests und ein begrenzter Umfang kleiner Probleme werden ebenfalls genannt. Betriebssystem- oder PHP-Upgrades, nicht unterstützte Module, größere Core-Upgrades und umfangreiche Probleme fallen dagegen in gesonderte Arbeit oder Angebote.[13]

Diese Grenze ist betrieblich glaubwürdig. Routinepatches sind planbar, wenn Abhängigkeiten unterstützt und Tests repräsentativ sind. Wird ein Plugin aufgegeben, eine Laufzeit veraltet, eine Schnittstelle eingestellt oder eine Datenänderung schwer rückgängig zu machen, wird Wartung zu einem Modernisierungsprojekt. Wer nur Routine budgetiert, sammelt Risiko genau dort, wo der Standardprozess endet.

Ein Patch-Hold benötigt Eigentümer, Ablaufdatum, Risikobewertung, kompensierende Kontrolle und erneute Entscheidung. Ohne diese Felder wird eine vorübergehende Ausnahme zu dauerhaftem, unsichtbarem Risiko. Umgekehrt kann eine ungeprüfte Sofortinstallation selbst einen Produktionsausfall erzeugen. Repräsentatives Staging, Rollback und eine externe Funktionsprüfung sind daher Teile derselben Sicherheitsleistung.

Systemintegration als Betrieb von Abhängigkeiten

IBC beschreibt Integrationsarbeit an Cloud-APIs, On-Premises-Umgebungen, Legacy-Servern, Sicherheitskontrollen, Staging, Funktions- und Leistungstests, Dokumentation, Nachüberwachung sowie Änderungen von Datenfeldern und Authentifizierungsabläufen.[17] Reale Produktionssysteme tauschen Identitäten, Bestellungen, Zahlungen, Dateien, Meldungen und Analysedaten über organisatorische Grenzen hinweg aus.

Jede Integration besitzt einen technischen und einen organisatorischen Vertrag. Technisch zählen Endpunkte, Schemas, Authentisierung, Zertifikate, Rate Limits, Wiederholungen, Timeouts, Reihenfolge, Validierung und Fehlersemantik. Organisatorisch zählt, wer ändern darf, wer alarmiert wird, wer Datenkorrekturen freigibt und wer Pause oder Rollback entscheidet. Dokumentation ist nur dann wirksam, wenn sie im Fehlerfall zur befugten Handlung führt.

Timeouts zeigen das Problem besonders deutlich. Der Sender kann keine Antwort erhalten, obwohl der Empfänger die Transaktion abgeschlossen hat. Eine blinde Wiederholung kann doppelte Buchungen oder Aufträge erzeugen. Idempotenzschlüssel, dauerhafte Journale, Abgleich und manuelle Reparatur sind notwendig, um divergierende Zustände wieder zusammenzuführen. Ein HTTP-Status allein erkennt weder einen wachsenden Rückstau noch fachlich falsche Daten.

Legacy-Systeme können funktionieren, obwohl ihre Bibliotheken nicht mehr unterstützt werden. Eine Zertifikatserneuerung kann koordinierte Wartungsfenster mehrerer Organisationen verlangen. Eine Firewallregel oder ein geheimer Schlüssel kann nur einer Person bekannt sein. Die daraus entstehenden Kosten liegen nicht im einmaligen Anschluss, sondern in laufender Dokumentation, Tests, Überwachung, Rechtepflege und Ersatzplanung.

Überwachung, Backup und Wiederherstellungsnachweis

IBC nennt Monitoring und Backup als Bestandteile seiner Dienste.[10][11][14][16] Das Vorhandensein eines Werkzeugs beweist aber nicht, dass es die richtigen Fehler erkennt, dass ein Alarm eine befugte Person erreicht und dass die Reparatur im Zielzeitraum gelingt. Reife Überwachung trennt Ressourcen, Netzwerk, DNS, Zertifikate, Anwendung, Integrationen und Geschäftsabläufe.

Ein einzelner HTTP-200-Test reicht nicht. Anmeldung, Suche, Zahlung, Dateiverarbeitung oder eine externe API müssen als wichtige Nutzerwege geprüft und mit internen Protokollen abgeglichen werden. Zu viele Warnungen führen zu Müdigkeit, zu wenige zu blinden Flecken. Schwellwerte, Eigentümer, Eskalation, Wartungsunterdrückung und Wiederherstellungsbestätigung müssen gepflegt werden.

Ein erfolgreicher Backup-Job ist kein erfolgreicher Restore. Für die Wiederherstellung braucht es Daten, Konfiguration, Geheimnisse, DNS, Zertifikate, Abhängigkeiten und die richtige Reihenfolge. Ein belastbarer Test misst Wiederanlaufzeit, Datenverlust, Integrität, Anwendungsstart, Wiederanschluss von Integrationen und eine fachliche Abnahme. Die Nennung eines Disaster-Recovery-Standorts ist eine Fähigkeit; sie ist kein Bericht über den Test eines bestimmten Kunden.

Aufsicht, Genehmigung und Ausnahmebehandlung

Die Seiten „Working With Us“ und „Service Plans“ beschreiben Anfragen, Priorisierung, Genehmigung, Wartungsverträge und Zusatzarbeit.[15][16] Genehmigung schützt vor unkontrollierten Änderungen, kann in einer Krise aber selbst zur Wartezeit werden. Für eine kritische Schwachstelle, kompromittierte Zugangsdaten oder eine fehlerhafte Integration sollte vorab feststehen, welche begrenzte Maßnahme ohne neue Einkaufsrunde zulässig ist.

Aufsicht ist nicht die Zahl der Meetings, sondern die fortlaufende Abstimmung von Soll- und Ist-Zustand. Registerdaten, Routen, DNS, Einrichtungen, Backups, Patches, Zugänge, Integrationen und Verträge haben oft verschiedene Eigentümer. Jede wesentliche Änderung benötigt eine Kette aus Freigabe, Ausführung, externer Beobachtung, Ausnahmeentscheidung und Rückfallmöglichkeit.

Die Gesamtkosten bestehen daher nicht nur aus Server und Bandbreite. Inventarpflege, Rechteprüfung, Lieferantenkoordination, Sicherheitsbewertung, Tests, Alarmtuning, Störungsreaktion, Kundenkommunikation, Nachanalyse, Wiederherstellungsübungen und Portabilität sind laufende Arbeiten. Ein Preisvergleich, der sie ausblendet, verlagert Kosten in spätere Ausnahmen.

Relevante Fehlermodi

  1. Veraltete Registeridentität: Kontakte oder Status passen nicht mehr zur tatsächlichen Zuständigkeit.
  2. Ungeklärter Routingursprung: Eine legitime Delegation kann schlecht dokumentiert oder nicht schnell widerrufbar sein.
  3. Fehlinterpretation von RPKI: unknown wird fälschlich als invalid oder als sicher behandelt.
  4. Verlust der DNS-Autorität: Domain und Dienst existieren, aber Registrar- oder DNS-Zugang ist nicht wiederherstellbar.
  5. Gemeinsamer Nameserver-Ausfall: Zwei Labels teilen Konten, Software oder Netzpfade.
  6. Unbefristeter Patch-Hold: Eine Ausnahme verliert Ablaufdatum und kompensierende Kontrolle.
  7. Nicht unterstützte Komponente: Routinewartung kann eine Abhängigkeit nicht mehr reparieren.
  8. Nicht repräsentatives Staging: Produktionsvolumen, Netz oder Integration werden nicht nachgebildet.
  9. Backup ohne Restore: Grüne Jobs können den Geschäftsdienst nicht wiederherstellen.
  10. Monitoring-Blindstelle: Ein Endpunkt antwortet, während der entscheidende Nutzerweg scheitert.
  11. Genehmigungslatenz: Die richtige technische Maßnahme wartet auf eine geschäftliche Entscheidung.
  12. Containment im Shared Hosting: Schutz der Plattform unterbricht einen Kunden, ohne klare Rückkehrkriterien.
  13. Divergierende Integrationszustände: Ein Timeout und eine Wiederholung erzeugen Duplikate oder Lücken.
  14. Lieferantenwechsel ohne Rückfall: Routing, DNS, Zertifikate, Backups und Zugänge ändern sich gleichzeitig.
  15. Abhängigkeit von Schlüsselpersonen: Nur eine Person kennt Kontext und Zugänge.

Diese Liste ist ein aus den öffentlichen Kontrollflächen abgeleitetes Risikomodell. Sie behauptet nicht, dass IBC oder ein Kunde einen dieser Vorfälle erlebt hat.

Fähigkeit, Zuverlässigkeit und Kundenergebnis

Fähigkeitsnachweise zeigen, dass Leistungen beschrieben und angeboten werden. Die IBC-Unterlagen stützen Hosting, Staging, Monitoring, Patching, Backup, Integration und Support.[10][11][13][14][15][16][17][18] APNIC stützt die Verbindung zwischen Unternehmen und Nummernressourcen; RIPE und DNS liefern begrenzte Außenbeobachtungen.[3][4][5][6][7][8][9]

Zuverlässigkeitsnachweise verlangen wiederholte Messungen mit definiertem Zeitraum und Umfang: externe Verfügbarkeit, Routingstabilität, Änderungserfolg, Restore-Tests, Patch-Compliance oder Vorfallhistorie. Die geprüften öffentlichen Quellen enthalten keinen vollständigen Längsschnitt über IBC-Kundendienste.

Kundenproduktionsergebnisse erfordern eine benannte Arbeitslast, Ausgangswert, Beobachtungsdauer, Geschäftsprozess und Zustimmung des Kunden. Eine erreichbare Infrastruktur kann fachlich falsche Transaktionen liefern; während eines technischen Ausfalls kann ein Kunde den Betrieb durch manuelle Verfahren aufrechterhalten. Aus einem Leistungskatalog darf kein Erfolg konstruiert werden.

Fragen für die Due Diligence

Ein Käufer sollte nach der vertragschließenden Identität, den Änderungsrechten für ASN und Präfix, der Autorisierung von AS56035, der ROA-Strategie, dem Wiederherstellungszugang zu Registrar und DNS, der aktuellen Rolle jedes Standorts, den Grenzen der Verfügbarkeitsmessung, dem letzten vollständigen Restore-Test, den abgedeckten Patch-Schichten, nicht unterstützten Komponenten, Staging-Abweichungen, Idempotenz und Abgleich von Integrationen, Notfallfreigaben sowie exportierbaren Daten und Konfigurationen fragen.

Eine gute Antwort muss nicht kompliziert sein. Ein überschaubares System mit klarer Zuständigkeit, überprüfbarer Evidenz und erprobter Wiederherstellung kann besser betreibbar sein als eine anspruchsvolle Architektur mit unklaren Grenzen.

Schlussfolgerung

Der öffentliche Fußabdruck von IBC Digital ermöglicht kein einfaches Qualitätsurteil, zeigt aber mehrere reale Verantwortungsebenen. Verzeichnis und APNIC bestätigen Unternehmen und Nummernressourcen. Das beobachtete Routing zeigt, dass registrierte Identität und laufender Ursprung auseinanderfallen können. DNS fügt eigene Rechte hinzu. Die IBC-Dokumente verbinden Hosting, Tests, Patching, Integration, Support und Kundengenehmigung.

Verlässliches Hosting ist Betriebsdisziplin, keine Funktionsliste. Fähigkeit braucht korrekte Umsetzung, Zuverlässigkeit braucht Langzeitmessung und ein Kundenergebnis braucht Belege aus dem realen Geschäft. Aufsicht, Integration, Wartung und Ausnahmebehandlung sind die dauerhaften Kosten, mit denen Register, laufende Konfiguration, externe Beobachtung, Vertragspflichten und Wiederherstellungsnachweise in Einklang bleiben.

Quellen

  1. BTW-Verzeichnis: Keltree Pty Ltd as trustee for The Kelly Family Trust T/A IBC Digital
  2. APNIC-Mitgliederverzeichnis
  3. APNIC Whois: AS10078
  4. APNIC RDAP: AS10078
  5. APNIC RDAP: 203.24.93.0/24
  6. RIPE NCC: Routingstatus AS10078
  7. RIPE NCC: angekündigte Präfixe von AS10078
  8. RIPE NCC: Routingstatus von 203.24.93.0/24
  9. RIPE NCC: RPKI-Validierung für AS56035 und 203.24.93.0/24
  10. IBC Digital: Website Hosting
  11. IBC Digital Hosting Services: Plans and Prices
  12. IBC Digital Hosting Terms and Conditions v2.2
  13. IBC Digital: Security Patch Management
  14. IBC Digital: Web Maintenance
  15. IBC Digital: Working With Us
  16. IBC Digital: Service Plans
  17. IBC Digital: System Integration
  18. IBC Digital: Our Team
  19. Wikimedia Commons: historischer HSG-Rechenzentrumsraum HSGH 022-001118