Zugangssysteme

Zugangssysteme wurden entwickelt, um herkömmliche Mechanismen zum Schutz des Zugangs von Räumen (z.B. Schloss, Pförtner), abzulösen. Diese altbewährten Schutzmechanismen zeichnen sich durch ihre Robustheit und Ausfallsicherheit aus. Sie bedienen sich, ähnlich der moderneren elektronischen Zugangssystemen, auch der Verfahren der Identifikation, welche in Kapitel 3 beschrieben wurden. So weist sich eine Person gegenüber einem Schloss durch den Besitz eines passenden Schlüssels aus. Obwohl es heutzutage Zylinderschließsysteme gibt, welche einem Schlüssel mehr Zugangsrechte als für eine Tür erlauben (z.B. Generalschlüssel, Gruppenschlüssel), ist das herkömmliche Schließsystem sehr unflexibel. Es ist unter anderem nicht möglich, Zugangsrechte zu ändern, ohne den Schlüssel zu tauschen. Die Rechte sind direkt mit dem Identifikationsmedium verbunden. Weiterhin wird ein solches Schließsystem in größeren Einrichtungen sehr teuer und unflexibel, da jedem Nutzer ein Schlüssel (incl. dazugehörigem Recht) ausgegeben werden muss. Eine Trennung von Identifikation und Recht ist für die Erhöhung der Flexibilität nötig.

Eine Weiterentwicklung, bei der Identifikation und Recht getrennt ist und welche mehrere Methoden zur Identifikation und Authentifikation beherrscht, ist der Ansatz eines Pförtners. Dieser identifiziert Personen durch Aussehen (Eigenschaften) oder durch ein Dokument (Ausweis) und authentifiziert diese durch den Vergleich von Merkmalen (Passfoto), welches auf diesem vertrauenswürdigen Dokument abgebildet ist. Nach erfolgreicher und sicheren Identifikation werden der Person gewisse Rechte verliehen. Dies kann einfach durch das Öffnen einer Schranke oder durch das Ausstellen eines Besucherausweises passieren.

Diesen Ansatz des Pförtners setzt ein elektronisches Zugangskontrollsystem um. Es identifiziert Objekte und gewährt den Zugang (Öffnen einer Tür) oder veranlasst die Gewährung von Rechten. Solche Systeme werden sowohl als Stand-Alone-Systeme, als auch als verteilte Systeme betrieben. Die Türen werden dabei von komplexen elektronischen Geräten gesteuert (im Folgendem als Steuereinheit bezeichnet). Diese Steuereinheiten sind meist über ein Kommunikationsnetz mit einem Server verbunden, welcher alle benötigten Daten vorhält.

Ein anderer Ansatz einer elektronischen Zugangskontrolle ist das elektronische Schloss. Jede Person bekommt einen Ausweis (Magnetkarte), auf dem die entsprechenden Rechte vermerkt sind. Jede Tür wird durch ein einfaches elektronisches Gerät gesteuert, welche autark arbeitet und keine Kenntnis von Personen oder Rechte hat. Es wird ausschließlich überprüft, ob die entsprechende Tür auf dem elektronischen Schlüssel vermerkt ist. Solche Systeme bieten weniger Leistung als ein Zutrittskontrollsystem. Zum Beispiel ist es meist nicht möglich, gestohlene oder verloren gegangene Ausweise zu sperren. Jedoch haben sie den Vorteil, dass die Ausweise einfach und preiswert in hohen Stückzahlen erzeugt werden können. Solche Systeme werden meist in Hotelanlagen eingesetzt.

Zutrittskontrollsysteme lassen sich aus meiner Sicht anhand ihrer Architektur in 3 Klassen einteilen.

Ein Stand-Alone-System ist die elektronische Umsetzung eines Pförtners. Es gibt ein Rechensystem mit einer Zugangssoftware, welche nicht vernetzt und nicht in andere Systeme integriert ist. Meist steuern solche Systeme genau eine Tür (z.B. Codeschloss).

Ein Online-System ist eine verteilte Zugangssteuerung. Es gibt meist einen Steuerserver, an welchen Steuerungscontroller (Clienten) angeschlossen sind, welche eine Tür steuern. Diese Controller lesen Identifikationsdaten (z.B. Identifikator einer Magnetkarte) ein und schicken diese zu dem zentralen Steuerungsserver. Dieser veranlasst entsprechend der definierten Rechte den Controller, die Tür zu öffnen. Dieses System birgt in großen Installationen die Gefahr, dass die Controller ihre Aufgabe nicht erfüllen können, falls die Kommunikation gestört ist.

Eine Weiterentwicklung ist das Offline-System. Dieses hält alle Daten, welche für die Identifikation und Vergabe von Rechten relevant sind, auf jeder Steuereinheit vor. Ein zentraler Steuercomputer verwaltet alle Rechte und erneuert die Datenbasis der Steuereinheiten. Diese Architektur hat den Vorteil, dass Ausfälle des Kommunikationsmediums keine schwerwiegenden Folgen haben. Jedoch benötigen die Controller in den Steuereinheiten genügend Rechenleistung und Speicher, um ihre Aufgaben zu erfüllen. Aus diesem Grund ist dieses System meist sehr teuer.

Darüber hinaus sind auch Kombinationen und Erweiterungen möglich. Optimal ist ein Offline-System, welches dennoch eine Echtzeitabfrage des Servers zulässt. Es verbindet die Robustheit eines Offline-Systems mit der Flexibilität eines Online-Systems.

Verteilte Zugangskontrollsysteme finden meist in größeren Einrichtungen Anwendung, da der Umgang mit herkömmlichen Schlüsseln unflexibel und teuer ist. Zusätzlich sind diese elektronischen Systeme mit Funktionen wie z.B. Zeiterfassung erweiterbar. Auch ist die Ad-Hoc Vergabe von Zugangsberechtigungen möglich (z.B. für Besucher), ohne einen Schlüssel zu vergeben.

Weiterhin gibt es in Einrichtungen, wo mehrere tausend Nutzer Zugang zu verschiedenen Raumzonen erlangen sollen und Rechte permanent geändert werden (z.B. vorübergehender Zugang zu Praktikumsräumen) keine Alternative zu verteilten elektronischen Zugangskontrollsystemen.

Forderungen an ein verteiltes Zugangssystem

Wie in der Einleitung beschrieben, ist es die Aufgabe eines Zugangssystemes, Nutzer (beliebige Objekte im weitesten Sinne) zu identifizieren und zu authentifizieren und danach den Zugang zu geschützten Objekten anhand von definierten Rechten zu gewähren oder geschützt belassen. Jedoch müssen im produktiven Einsatz eines solchen Systems weit mehr Anforderungen gestellt werden.

Sehr viele Forderungen lassen sich nur aus dem zukünftigen Einsatzgebiet ableiten. Solche Forderungen habe ich im Speziellen für den Einsatz eines solchen Systems an der TU Chemnitz abgeleitet.

Systemanforderungen

Systemanforderungen sind alle Forderungen an das Gesamtsystem, welche im weitesten Sinne Software betreffen. Darunter fallen auch Architekturentscheidungen, da diese direkt in Software umgesetzt werden können.

Folgende Anforderungen sollte eine offene, verteilte Zugangssteuerung erfüllen:

• Das System soll ortsunabhängig und flächendeckend als ein logische System arbeiten können. Es muss möglich sein, sowohl wenige Clienten anzubinden (z.B. in mittelständischen Betrieben) als auch große Konfigurationen zu realisieren (z.B. um weltweit verteilte Firmenfilialen auszurüsten). An der TUC muss es möglich sein, ein solches System campusweit einzusetzen.

• Das System soll skalierbar sein. Das heißt, es soll nahezu beliebig viele Nutzer bedienen können. Die Architektur des Gesamtsystems muss es zulassen, in Bezug auf Redundanz, örtliche Ausbreitung und Zahl der Nutzer erweiterbar zu sein.

• Das System muss Aufträge (Indentifizierung, Autorisierung und Ausführung einer Aktion anhand der vergebenen Rechte) in einer geringen Abarbeitungszeit bearbeiten, damit die allgemeine Produktivität gewährleistet bleibt. Das bedeutet, dass die Antwortzeiten klein bleiben müssen.

• Alle Komponenten des Systems sollen ausfallsicher konzipiert werden. Ein Ausfall von Technik oder Software sollte nicht die Funktionsfähigkeit des Gesamtsystems beeinflussen.

• Ausfälle von Technik und Software sollten erkannt und geeignet bekannt gegeben werden.

• Die nötige Datenbasis des Systems muss einfach änderbar sein. Das System darf nicht verlangen, redundante Daten an mehreren Stellen zu ändern.

• Das System sollte verschiedene Systeme zur Identifikation und Authentifikation nutzen könne. Die Schnittstellen hierfür sollten weitestgehend abstrahiert sein.

• Das System sollte mit beliebigen DBMS arbeiten können. Das System sollte verschiedene Datenbasen gleichzeitig nutzen können. Zum Beispiel sollten Identifikations- und Authentifikationsdaten, Log-Daten und Rechtedaten getrennt verwaltet werden.

• Die Vergabe der Rechte soll sehr flexibel gestaltet sein.

• Die Einbindung neuer Clienten muss unproblematisch sein. Die Konfigurationsarbeit muss überschaubar bleiben. Das System sollte eine vorbereitende Arbeit unterstützen, falls diese nötig wird. Das heißt, dass man neue Clienten ortsunabhängig vorbereiten können muss, um diese innerhalb von kurzer Zeit in den produktiven Betrieb einzubinden.

• Alle Änderungen an der Konfigurations- oder Rechtedatenbasis müssen nahezu ohne Verzögerung wirksam werden.

• Das System sollte eine Havariestrategie vorsehen. Diese sollte wirksam werden, sobald das Gesamtsystem oder Teile davon durch unvorhergesehene Einflüsse betriebsunfähig werden. So sollte es z.B. möglich sein, dass trotz ausgefallenem System Administratoren anhand von gespeichertem Wissen in den Clienten identifiziert und autorisiert werden um dennoch Zugang zu erhalten.

• Das laufende System sollte sich selbstständig überwachen und sich bei Fehlfunktionen oder Missbrauch in geeigneter Art und Weise bemerkbar machen. Es sollte weiterhin Schnittstellen zu anderen Systemüberwachungslösungen bieten (z.B. BigBrother).

• Das System sollte relevante Ereignisse speichern. Ereignisse einer definierten Relevanz dürfen dabei unter keinen Umständen verloren gehen. Die Relevanz muss konfigurierbar sein. Des Weiteren sollten Ereignisse unterschiedlicher Art und Relevanz anhand einer Konfiguration kategorisierbar sein. Die Abfrage der gespeicherten Ereignisse sollte nur differenziert möglich sein. Es muss zwischen administrativen und sicherheitsrelevanten Ereignissen unterschieden werden.

• Da es sich um ein hoch komplexes System handelt, müssen auch zahlreiche und flexible Schnittstellen existieren. Das System sollte einfach mit Fremdsystemen interagieren können. (z.B. mit dem Nutzermanagement MoUSe an der TUC)

• Das System sollte modular sein. Neue Anforderungen müssen durch Entwicklung neuer Komponenten einfach integrierbar sein.

• Es sollten Standardkommunikationssysteme in allen Schichten genutzt werden. (z.B. Ethernet, IP, XML-RPC)

• Das System muss robust sein. Bedienfehler, Systemfehler oder Programmierfehler sollten das System nicht funktionsunfähig machen.

Schnittstellenanforderungen

Das Zugangssteuerungssystem muss sowohl von fremden Systemen als auch von Menschen (Administrator) genutzt, konfiguriert und gesteuert werden.

Folgende abstrakte Aktionen müssen von diesen Nutzern ausgeführt werden können:

• Die Eigenschaften (z.B. Rechte- und Konfigurationsdatenbasis) des Systems müssen geändert werden. Dies ist z.B. zum Zwecke der Konfiguration nötig.
• Zur Überwachung des Systemzustandes müssen Eigenschaften jeder Komponenten netzweit ausgewertet werden können.
• Zur Steuerung des Systemes müssen Kommandos jeder Komponente netzweit übermittelt werden können.
• Steuerungssignale (Trigger) vom System müssen ausgewertet werden können.

Diese vier Aktionen sollten mittels verschiedener Mechanismen ausgeführt werden können. Zum Beispiel:

• über eine Webschnittstelle,
• über eine API für verschiedene Programmiersprachen,
• über Komandozeilentools.

Die Vielfalt der Zugriffsmethoden ist notwendig, da das System von unterschiedlichen Fremdsysteme (z.B. Menschen, MoUSe) genutzt und gesteuert werden soll, welche jeweils unterschiedliche Fähigkeiten zur Kommunikation besitzen. Dabei es ist sinnvoll, dass all diese Mechanismen über eine einheitliche Schnittstelle mit dem Zugangssystem kommunizieren. Diese Schnittstelle sollte systemunabängig und einfach sein. Für solche Aufgaben wurde das Protokoll XML-RPC [11] entwickelt.

Marktanalyse

Recherchen im Internet haben ergeben, dass es nur wenige Angebote für fertige Systemlösungen gibt, welche unseren Ansprüchen entsprechen. Dabei spielen am Markt nur die Firmen effeff-Alarm mit ihrem Zugangssystem MultiAccess [9] und die Firma Siemens mit den Produkten [25] ,,SIPORT NT'', ,,SIPORT NT light'' und ,,CerPass'' eine Rolle.

Beide zeichnen sich durch einen großen Funktionsumfang und vor allem eine Integration betriebswirtschaftlicher Funktionen wie z.B. Zeiterfassung, Besuchermanagement, Personalverwaltung und Schnittstellen für die Lohnbuchhaltung aus.

Beide Firmen setzen als zentrales Steuerungselement eine Windows-Applikation ein und kommunizieren über ein nicht offen gelegtes Protokoll mit den Steuereinheiten. Über eine Möglichkeit der Integration und Nutzung von Drittsystemen werden keine Aussagen getroffen. Gespräche mit lokalen Firmen und Erfahrungen mit dem aktuellen System an der TUC haben die Vermutung bestätigt, dass Hersteller von Zugangssystemen keine offene Programmierschnittstellen anbieten und interne Protokolle nicht offen legen wollen.

Zusammenfassend ist zu sagen, dass kommerzielle Lösungen unseres Problems auf dem Markt existieren, diese jedoch sehr schwierig und kostenintensiv in die Geschäftsprozesse des URZ integrierbar sind. Da von einem Einkauf eines kommerziellen Zugangssystem abgesehen werden kann, wir an dieser Stelle auf einen Produktvergleich verzichtet.