Sicherheitsroboter im Rechenzentrum: TIER III Anforderungen und reale Architektur

Ein Sicherheitsroboter im Rechenzentrum ist kein Wachgänger auf Rädern, sondern ein konfigurierbares Element einer geordneten Sicherheitsarchitektur, deren Regeln nicht der Hersteller schreibt, sondern der Betreiber des Standorts und die Aufsichten, die ihn prüfen.

Wer einen autonomen Rundgang in einem TIER III Rechenzentrum plant, plant nicht ein Gerät, sondern eine Schnittstelle. Das Gerät selbst ist die kleinste Variable in der Gleichung. Die größeren Variablen sind die Verfügbarkeitsklasse nach TIA-942, das Informationssicherheits-Managementsystem nach ISO 27001, der IT-Grundschutz des BSI, die Zonenlogik des physischen Zutritts, das Brandschutzkonzept und die Frage, wer im Ausnahmefall entscheidet und wer haftet. Diese Variablen stehen vor der Entscheidung über die Hardware. Wer sie nachträglich klärt, baut zurück, was er gerade gebaut hat.

Die Verfügbarkeitsklasse als Rahmen, nicht als Etikett

TIER III ist eine Verfügbarkeitsklasse mit konkreten architektonischen Konsequenzen. Concurrent Maintainability heißt, dass jede Komponente der unterstützenden Infrastruktur gewartet werden kann, ohne dass die IT-Last unterbrochen wird. Diese Eigenschaft betrifft Strom, Kühlung, Verkabelung und Brandschutz. Sie betrifft auch die physische Sicherheit, weil die physische Sicherheit Teil der unterstützenden Infrastruktur ist und nicht ein nachgelagerter Service.

Ein Sicherheitsroboter, der in einem TIER III Standort patrouilliert, muss in diese Logik eingepasst werden. Er darf nicht zu einer Komponente werden, deren Ausfall den Wachgang stoppt. Konkret bedeutet das eine redundante Architektur des Wachgangs. Entweder zwei Geräte, die sich gegenseitig ablösen können, oder ein Gerät plus ein definierter manueller Rückfallprozess, der ohne Improvisation greift. Wer die Redundanz nicht spezifiziert, untergräbt die Klassifizierung des Standorts, nicht in der Theorie, sondern in der nächsten Auditierung durch das Uptime Institute oder eine gleichwertige Instanz.

Die Wartung des Roboters muss ebenfalls concurrent maintainable sein. Akkutausch, Sensorreinigung, Firmware-Aktualisierung, Kalibrierung. Jeder dieser Vorgänge muss in einem Zeitfenster ausführbar sein, in dem der Standort weiterhin als überwacht gilt. Das verlangt eine Service-Logik, die sich nicht an der Bequemlichkeit des Herstellers orientiert, sondern an den Betriebsfenstern des Rechenzentrums. Boswau + Knauer hat diese Logik in den eigenen Produkten verankert. Geplante Wartung, dokumentierte Wartung, durchgeführt in Fenstern, die mit dem Betreiber abgestimmt sind, nicht außerhalb seiner Kenntnis.

Die zweite Konsequenz aus TIER III betrifft die Stromversorgung des Roboters selbst. Sein Ladepunkt ist eine Last im Stromkonzept des Standorts. Sie ist klein, aber sie ist nicht null, und sie muss in der USV-Planung sichtbar sein. Wer den Ladepunkt an eine beliebige Steckdose hängt, hat im nächsten Audit eine Beanstandung. Wer ihn an die abgesicherte Versorgung anschließt, hat eine Last dokumentiert und damit eine kontrollierte Position im Gesamtsystem. Die Differenz ist klein im Aufwand und groß in der Wirkung auf die Klassifizierung.

ISO 27001 und die Frage, was der Roboter sieht

ISO 27001 verlangt ein Informationssicherheits-Managementsystem mit klar dokumentierten Kontrollen. Annex A enthält die physischen Kontrollen, darunter A.7 zur physischen Sicherheit, der die Überwachung von Räumen und die Kontrolle des Zutritts regelt. Ein Sicherheitsroboter, der in solchen Räumen operiert, ist nicht nur ein Sensor, sondern eine Datenquelle, deren Output unter die Vertraulichkeits-, Integritäts- und Verfügbarkeitsanforderungen des Managementsystems fällt.

Konkret heißt das, dass die Videodaten, die Sensordaten und die Bewegungsdaten des Roboters klassifiziert werden müssen. Wer sie klassifiziert hat, weiß, wie lange sie gespeichert werden, wer sie sehen darf, wie sie übertragen werden und wann sie zu löschen sind. Die Antworten müssen in den Dokumenten des Managementsystems stehen, nicht in der Erinnerung eines Operators. Ein häufiger Fehler ist die Annahme, dass der Hersteller diese Klassifizierung mitliefert. Das tut er nicht. Er liefert die Funktion. Die Klassifizierung liegt beim Betreiber, und sie muss im Audit nachweisbar sein.

Die Datenhaltung selbst ist eine architektonische Frage. Werden die Daten lokal auf dem Roboter gespeichert, in einer Edge-Komponente am Standort, in der zentralen Leitstelle des Betreibers oder in einer Cloud-Umgebung des Herstellers? Jede dieser Optionen hat unterschiedliche Konsequenzen für ISO 27001, für die Datenschutz-Grundverordnung und für die internen Richtlinien des Standorts. Eine Cloud-Umgebung des Herstellers ist in einem TIER III Rechenzentrum selten zulässig, weil sie eine Vertrauensgrenze überschreitet, die das Managementsystem üblicherweise nicht überschreiten will. Die saubere Lösung ist die lokale Verarbeitung mit definierten Schnittstellen zur Leitstelle des Betreibers. Boswau + Knauer baut die eigenen Plattformen so, dass diese Trennung möglich ist, ohne dass die Funktion darunter leidet.

Eine dritte Konsequenz aus ISO 27001 betrifft die Lieferantensteuerung. Der Hersteller des Roboters ist ein Lieferant im Sinne des Managementsystems. Er muss bewertet, geprüft und vertraglich gebunden werden. Das verlangt eine Vereinbarung zur Auftragsverarbeitung, eine Beschreibung der Sicherheitsmaßnahmen auf Seiten des Herstellers und ein Verfahren zur Meldung von Vorfällen. Wer diese Vereinbarungen nicht hat, hat eine Lücke im Audit, die sich nicht durch die Qualität des Geräts schließen lässt.

BSI-IT-Grundschutz und die Zonenlogik

Der IT-Grundschutz des BSI ordnet Standorte in Zonen. Diese Zonen sind nicht abstrakt, sondern an konkrete Schutzziele gebunden. Eine Außenzone, eine Empfangszone, eine Bürozone, eine Betriebszone, eine Sicherheitszone und eine Hochsicherheitszone. Der Roboter operiert in einer oder mehreren dieser Zonen, und für jede Zone gelten unterschiedliche Anforderungen an Authentifizierung, Bewegungsfreiheit und Datenerfassung.

Die Bewegung des Roboters zwischen den Zonen ist der kritischste Punkt der Architektur. Wer darf den Übergang zwischen Sicherheits- und Hochsicherheitszone passieren? Welche Authentifizierung greift? Welche Sensorik wird beim Übergang aktiviert oder deaktiviert? Diese Fragen sind in den meisten Standorten für Personen geklärt und für Maschinen nicht. Genau hier liegt die Aufgabe einer ordentlichen Integrationsplanung. Der Roboter muss in der Zutrittskontrolle als eigenständige Identität geführt werden, mit definierten Rechten, definierten Zeitfenstern und definierten Routen. Wer ihm einen menschlichen Mitarbeiter als Begleiter zuordnet, hat das Problem nur verschoben, nicht gelöst.

Innerhalb der Hochsicherheitszone, in der die produktiven Server stehen, ist die Datenerfassung des Roboters besonders sensibel. Bilder von Racks, von Verkabelung, von Statusanzeigen können kompromittierende Informationen enthalten. Die Konfiguration des Roboters muss diese Sensibilität abbilden. Bestimmte Aufnahmen werden nur in einem geschlossenen System verarbeitet, bestimmte Aufnahmen werden gar nicht gespeichert, bestimmte Aufnahmen werden vor der Übertragung anonymisiert. Diese Regeln sind technisch umsetzbar, aber sie müssen vor der Inbetriebnahme festgelegt sein. Nachträgliche Anpassungen sind teuer und führen oft zu Lücken, weil die ursprüngliche Logik nicht mehr vollständig nachvollziehbar ist.

Die BG BAU, der GDV, der VdS und der BDSW haben für angrenzende Bereiche jeweils eigene Hinweise und Standards entwickelt, die in der Praxis ergänzend herangezogen werden. Sie ersetzen den IT-Grundschutz nicht, aber sie schärfen einzelne Anforderungen, etwa zur Verbindung von technischen und organisatorischen Maßnahmen. Wer ein Rechenzentrum sichert, prüft, welche dieser Standards für seinen Versicherer und seinen Auditor verbindlich sind, und richtet die Architektur danach aus.

Integration in Gebäudeleittechnik und Zutrittskontrolle

Ein Rechenzentrum betreibt eine Gebäudeleittechnik, eine Zutrittskontrolle, eine Brandmeldeanlage, eine Videoüberwachung und ein Energiemanagement. Diese Systeme sprechen über etablierte Protokolle und haben gewachsene Schnittstellen. Ein Sicherheitsroboter, der in diese Landschaft eingebracht wird, muss sich an die bestehenden Protokolle anpassen, nicht umgekehrt. Wer den Betreiber zwingt, seine Leittechnik wegen eines Roboters zu verändern, verliert das Projekt, bevor es beginnt.

Die saubere Integration läuft über drei Pfade. Der erste Pfad ist die Zutrittskontrolle. Der Roboter wird als Identität registriert, erhält Rechte, übergibt Authentifizierungsdaten an die Türsteuerungen und wird in den Logs der Zutrittskontrolle dokumentiert wie jede andere Identität. Der zweite Pfad ist die Videoüberwachung. Die Bilder des Roboters fließen in das bestehende Video-Management-System ein, mit denselben Speicher- und Auswerteregeln wie die stationären Kameras. Der dritte Pfad ist die Leitstelle. Die Alarme und Ereignisse des Roboters laufen in dieselbe Leitstelle wie alle anderen Alarme, mit derselben Priorisierung und denselben Eskalationsregeln.

Diese drei Pfade sind nicht selbstverständlich, weil viele Hersteller eine eigene Plattform mitbringen, die parallel zur bestehenden Landschaft laufen soll. Eine parallele Plattform schafft eine zweite Leitstelle, eine zweite Datenhaltung und eine zweite Verantwortlichkeit. Damit verdoppelt sich der Aufwand, ohne dass sich der Schutz verdoppelt. Boswau + Knauer hat sich gegen diese Logik entschieden und liefert Plattformen, die in bestehende Systeme einspeisen, ohne sie zu ersetzen. Die Konsequenz ist, dass die Integration länger dauert als bei einem geschlossenen System, dafür hält sie. Im Buch zu BOSWAU + KNAUER wird diese Haltung als Plattformansatz beschrieben, der nicht in Quartalen denkt, sondern in Dekaden.

Die Latenz zwischen Roboter und Leitstelle ist eine eigene Größe, die separat geplant werden muss. Ein Ereignis, das auf dem Roboter erkannt wird, muss innerhalb einer Reaktionszeit, die im einstelligen Sekundenbereich liegt, in der Leitstelle ankommen und dort eine Handlung auslösen können. Wer diese Reaktionszeit nicht spezifiziert, baut ein System, das im Vorfall überrascht. Spezifiziert wird sie über die Netzwerkarchitektur, die Priorisierung des Datenverkehrs und die Architektur der Verarbeitung. Lokale Vorverarbeitung auf dem Roboter ist hier der entscheidende Hebel, weil sie die kritischen Entscheidungen aus der Netzwerklatenz herauslöst.

Brandschutz und der Sonderfall der Löschanlage

Rechenzentren betreiben in der Regel Inertgaslöschanlagen oder Sauerstoffreduktionsanlagen. Beide Systeme haben Konsequenzen für jedes mobile Gerät, das sich in den geschützten Räumen aufhält. Eine Inertgasflutung verändert die Atmosphäre innerhalb von Sekunden. Eine Sauerstoffreduktion hält den Sauerstoffgehalt dauerhaft auf einem Niveau, das für offene Flammen ungeeignet ist. Beide Bedingungen müssen in der Konstruktion des Roboters berücksichtigt sein, sonst wird das Gerät selbst zur Quelle eines Risikos.

Die Reaktion des Roboters im Brandfall ist in der Architektur vorab festzulegen. Drei Optionen sind in der Praxis verbreitet. Erstens das sofortige Verlassen der betroffenen Zone in eine sichere Position. Zweitens das Verharren an einer definierten Stelle, an der das Gerät die Räumung nicht behindert. Drittens die Übernahme einer aktiven Rolle in der Räumungsverifikation, etwa durch Bildübertragung an die Leitstelle, bevor die Löschanlage auslöst. Welche Option gewählt wird, hängt vom Konzept des Standorts ab. Die Entscheidung ist nicht trivial, weil die falsche Wahl im Ernstfall sichtbar wird, nicht in der Übung.

Die Schnittstelle zur Brandmeldeanlage ist sicherheitsrelevant und entsprechend einzustufen. Sie muss auf einer Ebene laufen, die nicht über die allgemeine Datenleitung des Roboters geht, sondern über einen separaten, abgesicherten Kanal. Diese Trennung ist im VdS-Umfeld etablierte Praxis und wird im Audit erwartet. Wer den Brandfall über dieselbe Leitung führt wie die Routinetelemetrie, akzeptiert, dass im Vorfall der Wettbewerb der Datenpakete über die Reaktionsgeschwindigkeit entscheidet. Das ist keine akzeptable Architektur.

Die TÜV-Prüfung der gesamten Anlage berücksichtigt den Roboter nur dann zuverlässig, wenn er als Teil des Sicherheitskonzepts dokumentiert ist. Eine nachträgliche Aufnahme ist möglich, aber sie verlangt eine erneute Bewertung des Konzepts. Wer von Beginn an mitdokumentiert, spart sich diesen Schritt. Die Mehrarbeit in der Planung zahlt sich in der Wiederholung der jährlichen Prüfung mehrfach zurück.

Was bleibt

Ein Sicherheitsroboter im TIER III Rechenzentrum ist eine Investition in eine Architektur, nicht in ein Gerät. Die Architektur umfasst die Verfügbarkeitsklasse, das Managementsystem, den Grundschutz, die Leittechnik, den Brandschutz und die Lieferantensteuerung. Wer eine dieser Ebenen vernachlässigt, baut ein Element, das in der nächsten Auditierung als Risiko erscheint, nicht als Lösung.

Die Reihenfolge der Entscheidungen ist umkehrbar. Sie beginnt mit der Architektur und endet mit dem Gerät, nicht andersherum. Wer die Reihenfolge respektiert, hat am Ende ein System, das in den Audits trägt, in den Vorfällen reagiert und in der Wartung planbar bleibt. Wer die Reihenfolge umkehrt, hat ein Gerät, das beeindruckt, bis es geprüft wird.

Wer in der eigenen Organisation an dem Punkt steht, an dem die Architekturfragen offen sind und die Technologie bereits diskutiert wird, der findet in einem strukturierten Gespräch von sechzig Minuten den Rahmen, in dem sich die Reihenfolge wiederherstellen lässt. Für Standorte, deren Entscheidung weiter fortgeschritten ist, ist ein Audit von drei bis fünf Tagen vor Ort der Weg, der die offenen Punkte ohne weitere Verzögerung schließt. Beide Wege sind im hinteren Teil des Buches BOSWAU + KNAUER, Vom Bau zur Sicherheitstechnologie, beschrieben.

Häufige Fragen

Welche Sicherheitsstandards verlangt ein TIER III Rechenzentrum?

Maßgeblich sind die TIA-942 für die bauliche und elektrische Klassifizierung, das Uptime Institute für die Verfügbarkeitskategorie, ISO 27001 für das Managementsystem und der IT-Grundschutz des BSI für die operative Umsetzung. Hinzu kommen je nach Sektor branchenspezifische Vorgaben, etwa für KRITIS-Betreiber das BSI-Gesetz und die Verordnungen zu kritischen Infrastrukturen. Der VdS und der TÜV liefern in den Audits die technische Prüftiefe. Wer einen Roboter integriert, muss seine Architektur in jedem dieser Rahmen dokumentieren können, nicht nur in einem.

Wie integriert sich ein Roboter mit BMS und Zutrittskontrolle?

Über drei Schnittstellen. Die erste Schnittstelle ist die Zutrittskontrolle, in der der Roboter als eigene Identität mit Rechten, Routen und Zeitfenstern geführt wird. Die zweite Schnittstelle ist das Video-Management-System, in das die Bilddaten des Roboters einspeisen. Die dritte Schnittstelle ist die Leitstelle, in die Alarme und Ereignisse mit derselben Eskalationslogik wie alle anderen Quellen einlaufen. Die Integration funktioniert, wenn der Roboter sich an die etablierten Protokolle anpasst und keine parallele Plattform mitbringt, die die bestehende Landschaft ersetzen will.

Welche Latenzen sind kritisch?

Kritisch ist die Zeit zwischen Ereigniserkennung auf dem Roboter und Handlung in der Leitstelle. Sie sollte im einstelligen Sekundenbereich liegen, in besonders sensiblen Zonen darunter. Die Latenz setzt sich aus der lokalen Verarbeitungszeit, der Netzwerklaufzeit und der Verarbeitungszeit in der Leitstelle zusammen. Lokale Vorverarbeitung auf dem Roboter ist der wichtigste Hebel zur Senkung der Latenz, weil sie die kritischen Entscheidungen aus der Abhängigkeit von der Netzwerkstrecke löst. Die Schnittstelle zur Brandmeldeanlage hat eigene, strengere Latenzanforderungen und wird über einen separaten, abgesicherten Kanal geführt.

Wie wird im Brandfall reagiert?

Die Reaktion ist in der Architektur vorab festzulegen. Üblich sind drei Optionen. Erstens das Verlassen der betroffenen Zone in eine sichere Position vor Auslösung der Löschanlage. Zweitens das Verharren an einer definierten Stelle, die die Räumung nicht behindert. Drittens die aktive Unterstützung der Räumungsverifikation durch Bildübertragung an die Leitstelle. Welche Option gewählt wird, hängt vom Brandschutzkonzept des Standorts ab, vom Typ der Löschanlage und von der TÜV-Bewertung des Gesamtsystems. Der Roboter darf im Brandfall keine Sekundärrisiken erzeugen, etwa durch Akkutechnologie, die unter Inertgasbedingungen instabil wird.