Migration zu IP-basierenden Systemen
Physische Sicherheit auf IP-Basis
Der finanzielle Aufwand für Wartung und Betrieb traditioneller Systeme für die physische Zutrittskontrolle (Access Control Systems, ACS) steigt kontinuierlich. Immer häufiger erreichen proprietäre Komponenten nach Jahrzehnten das Ende ihrer Lebensdauer und sind nur noch unter erheblichen Kosten ersetzbar. Die Migration eines bestehenden, zentralisierten oder verteilten ACS zu einem IP-basierenden Pendant verspricht Unternehmen in dieser Situation gleich mehrere Vorteile.
Diese Pluspunkte gelten im Betrieb, bei Erweiterungen und bei Anpassungen der gesamten physischen Sicherheitsinfrastruktur. Dazu gehören im Einzelnen etwa die Standardisierung der Infrastruktur sowie die Ablösung proprietärer Geräte und der Verkabelung. Die Verlagerung intelligenter Funktionalität an die Tür reduziert Fehlerpunkte und optimiert das Monitoring und Management. Erweiterungen und die Modifikation der Infrastruktur werden künftig einfacher. Außerdem lassen sich zum Beispiel ein ACS und die Videoüberwachung sowie andere Sensoren in einem einzigen System vereinen.
Neue Funktionalität
IP-basierende Systeme ermöglichen darüber hinaus die Nutzung höher entwickelter Funktionen, die in traditionellen Systemen gar nicht zur Verfügung stehen. Dies gilt gleichermaßen für das Management der Infrastruktur und die verwendeten Geräte, deren Innovationszyklus sich in den letzten Jahren deutlich beschleunigt hat. Durch die Unterstützung von PoE (Power over Ethernet) über Kategorie 5e/6 für Controller, Kartenleser und Türschlösser sinken zudem die Kosten für die Verkabelung. Zu den erweiterten Funktionen gehören:
- Multi-Site-Management und Monitoring,
- Skalierbarkeit bei wachsender Zahl von Geräten und Türen,
- PoE-Türkontroller und erweiterte Hardwareoptionen,
- globales Management der Karteninhaber, eine Karte für alle Niederlassungen,
- automatisiertes Karteninhaber- und Rechte-Management über Microsoft Active Directory sowie
- Integration von Drittanbieterlösungen über IP.
In welchem Umfang diese Vorteile zu realisieren sind, hängt im Wesentlichen davon, ob sich Unternehmen für eine integrierte, offene oder eine Unified-Plattform entscheiden. Häufig sind zum Beispiel Videoüberwachung und ACS mittels APIs integriert, um Zugangsalarme an bestimmte Video-Feeds zu koppeln. Dies erfordert jedoch umfangreiche Regeldefinitionen sowie letztlich auch die Arbeit in zwei Interfaces. Offene Plattformen integrieren die Hardware verschiedener Anbieter, verwenden dabei aber nicht zwingend Industriestandards.
Die Funktionen stehen über eine generische Integrationsschicht und spezifische Treiber für jedes unterstützte Gerät bereit. Diese Strategie funktioniert gut bei Geräten mit einem festen und genau definierten Funktionsumfang. Wie zuvor bei der Videoüberwachung geht der Trend jedoch auch bei ACS zu Industriestandards. Mit offenen Unified-Plattformen entsteht daher ein nochmals anderer Ansatz: Nicht-proprietäre Geräte sind in einem einzigen Interface und in eine einzige Backend-Server-Infrastruktur integriert, um ein einheitliches Management und Monitoring von ACS, Video, Feueralarmen etc. zu ermöglichen.
Die Möglichkeit zur flexiblen Verwendung nicht-proprietärer Geräte kann zudem entscheidend sein, wenn komplexe Gebäudestrukturen vorliegen oder Zonen mit verschieden Sicherheitsanforderungen abzubilden sind. Ein Beispiel aus der Praxis ist das Rathaus mit angeschlossener Zentralbibliothek des Manchester City Council. Der Bau aus dem 19. Jahrhundert weist auf mehr als 63.000 m2 sowohl Bereiche mit hohem Publikumsverkehr als auch besonders kritische Archivräume auf. Durch die Verwendung einer offenen Unified-Architektur konnten dort unterschiedlichste Geräte zum Einsatz kommen, darunter 205 Smartcard-Reader in allgemeinen Bereichen, 22 drahtlose Lesegeräte in Bereichen, die eine hohe Flexibilität erfordern, und 23 Lesegeräte mit Tastatur, von denen drei für strengere Sicherheitsanforderungen in sensibleren Bereichen außerdem mit einer biometrischen Lesefunktion ausgestattet sind. Zusätzlich integriert sind 170 Kameras sowie Systeme für Eindringungserkennung, Brandmeldung, Notbeleuchtung, Überflutungserkennung sowie Aufzugsalarme und SIP-fähige IP-Sprechanlagen.
Bei derart vielen genutzten Systemen ist die Unterstützung der Bediener durch ein angepasstes Management-Konzept unerlässlich. Der Manchester City Council nutzt daher eine kartenbasierende Oberfläche für die 2D- und 3D-Navigation innerhalb der Gebäudefläche, mit deren Hilfe das Sicherheitspersonal Geräte lokalisiert, Kameras zoomt, Türen entriegelt und auf Alarme von Drittanbietersystemen reagiert. Hinterlegte Verfahrensabläufe für bestimmte Alarmtypen stellen die Einhaltung behördlicher Vorgaben sicher und liefern Mitarbeitern eindeutige Schritt-für-Schritt-Anweisungen in Pop-up-Fenstern.
Was kann bleiben?
Am Anfang steht die Frage nach den bestehenden Zugangskarten: Sind die darauf kodierten Berechtigungsdaten und das Kartenformat weiterzuverwenden? Die Migration zu einem IP-ACS wird wesentlich leichter, wenn das existierende System nicht-proprietäre Karten und Kartenleser einsetzt, die zum Beispiel das Standard-26-Bit- oder Wiegand-Format nutzen. Ein fortschrittliches IP-ACS wird darüber hinaus in der Lage sein, selbst bei unbekanntem Kartenformat auch proprietäre Berechtigungsdaten zu unterstützen.
Voraussetzung dafür ist allerdings, dass der Kartenleser die gesamten Berechtigungsdaten ausgeben kann. Verwenden die Kartenleser jedoch auch bei der Kommunikation mit dem ACS ein proprietäres Format, sind sehr wahrscheinlich alle Bestandskartenleser im Rahmen des Migrationsprojekts zu ersetzen.
Weiteres Augenmerk sollte den intelligenten Controllern sowie den dahinterliegenden Interface-Panels gelten, die Kartenleser und Türhardware mit dem Controller verbinden. Basieren die bestehenden Controller auf einer offenen Architektur, die mehrere Hersteller unterstützen, können sie möglicherweise weiterverwendet werden.
Netzwerk und Verkabelung
Bei der Analyse der vorhandenen Softwarekonfiguration muss exakt definiert sein, was genau der Betreiber in das neue System portieren will. An erster Stelle wird es dabei um die nativen Daten in der Bestandsdatenbank gehen. Möglicherweise sind jedoch auch Drittanbieterkomponenten über ein SDK in die vorhandene Konfiguration integriert. Personen- und Berechtigungsdaten sollten zunächst über die verfügbaren Export-Tools oder entsprechende Skripte in ein Standarddateiformat wie CSV oder in eine Excel-Datei übertragen werden. Dort lassen sie sich analysieren, falls nötig anpassen und danach in das neue System importieren. Unterstützung für CSV- und XLS-Dateien ist bei einem modernen ACS Standard.
IP-ACS platzieren den Controller an der Tür und verwenden PoE-Endgeräte, daher ist eine entsprechende Kategorie-5- oder -6-Verkabelung inklusive der benötigten Netzwerkkomponenten (etwa Switches) zu planen. Soll ein verteiltes System mit lokalen und abgesetzten Niederlassungen migriert werden, ist zusätzlich zu prüfen, ob Latenzzeiten und Bandbreiten für die Multi-Site-Kommunikation in einem IP-ACS geeignet sind.
Vor der Migration sollten Verantwortliche zudem prüfen, ob die Verkabelung vom Kartenleser zum Panel, Interface-Modul zum Controller und I/O zu Interface-Modulen den Anforderungen des neuen Systems (auch hinsichtlich des Leitungsquerschnitts) entspricht und sogar erhalten werden kann. Standard- oder nicht-proprietäre Verkabelung vom Kartenleser zum Interface-Modul sowie Controller-Verkabelung, wie sie zum Beispiel von Kartenlesern mit Wiegand-, Serial- (RS232, RS422, RS485) oder Clock-and-Data-Interface (ABA) verwendet wird, lässt sich häufig weiterverwenden. Proprietäre Kartenleser nutzen dagegen oft weniger Leitungen, sodass die Migration zu nicht-proprietären Geräten zusätzliche Verkabelung erfordert.
Migrationsschritte
Eine erfolgreiche Migration von einem Bestands- zu einem IP-ACS hängt ganz wesentlich von einer umfassenden Bestandsaufnahme am Anfang ab. Nur nach einer eingehenden Analyse der bestehenden Infrastruktur lässt sich eine Entscheidung darüber treffen, ob und in welchem Umfang Teile des Bestands-ACS erhalten bleiben können. Die Ergebnisse dieser Analyse entscheiden also direkt über Kosten, Dauer und Umfang des Migrationsprojekts (siehe Kasten auf Seite 33).
Bei den ersten Schritten werden Unternehmen zunächst überwiegend mit einem Systemintegrator oder Hersteller zusammenarbeiten, um den grundlegenden Plan aufzustellen. Die nachfolgenden Umsetzungsschritte erfordern dann Support-Techniker und IT-Ingenieure, die das konkrete Design und die Konfiguration des IP-basierenden Systems sowie die Integration aller Komponenten übernehmen.
Bestandsaufnahme des bestehenden ACS:
Standort elektrischer und Telekommunikationsanlagen, Plan der Verkabelung und Stromversorgung, Liste aller vorhandenen Komponenten und Softwarefunktionen, die in das neue System übergehen sollen.
Anforderungen des neuen Systems analysieren:
Hardware, Software, Netzwerk, Verkabelung, Stromversorgung.
Gebäudebegehung:
Entfernungen zwischen Access Control Panels, Stromquellen und Kartenlesern messen, Gerätestandorte verifizieren.
Kompatibilität von Bestandsgeräten testen:
Der Systemintegrator oder Hersteller prüft die Wiederverwertbarkeit von Controllern, Interface-Modulen, Karten und Lesegeräten.
Anforderungen an neues ACS definieren:
Auf Basis der bislang gewonnen Informationen über Bestandssysteme sowie über das neue System schreibt der Verantwortliche die Anforderungen an Netzwerk und IP-ACS fest.
Bestandsdatenbank analysieren und exportieren:
Export in Standard-Dateiformate.
Migration planen:
Um Downtime zu minimieren, ist soviel Hardware und Software wie möglich parallel zu migrieren, Drittanbietersoftware oder Eigenentwicklungen in den Plan einbeziehen.
Neues IP-ACS testen:
Soweit möglich Tests im Parallelbetrieb mit dem bestehenden System durchführen.
Migration durchführen:
Schrittweise Umstellung und Kontrolle des Migrationserfolgs durch den Systemintegrator und das Unternehmen.
Lesen Sie mehr zum Thema
