Sicherheit ist eine Grundtugend der IT. Umso mehr, wenn durch unbefugten Zugriff auf die Systeme Menschenleben und hohe Sachwerte in Gefahr geraten. Entsprechend aufwändig ist das Sicherheitskonzept im German Space Operations Center (GSOC) des Deutschen Zentrums für Luft- und Raumfahrt in Oberpfaffenhofen. Hier wird unter anderem rund um die Uhr das Columbus-Modul der internationalen Raumstation ISS gesteuert.

Drei separate Netze

Wie in vielen anderen Unternehmen mit hohen Sicherheitsanforderungen basiert das Konzept des GSOC auf getrennten Netzwerken unterschiedlicher Schutzstufen, die keine Berührungspunkte haben: Im "Ops"-Netz findet die eigentliche Steuerung des Forschungsmoduls im Erdorbit statt, darunter die Kontrolle der lebenserhaltenden Systeme im Columbus-Modul. Hier gelten - damit kein Unbefugter Kommandos an die ISS absetzen kann - strengste Sicherheitsrichtlinien, wie sie zum Beispiel in Banken üblich sind.

Parallel dazu existiert das "Ops-Support"-Netz. In diesem Segment laufen verschiedene Hilfsmittel für die Flight Controller, etwa ein Tool zur minutiösen Tagesplanung der ISS-Besatzung. Die Sicherheitsansprüche hier sind mit den Standards in unternehmenskritischen Bereichen anderer Industrien vergleichbar: Ein Fehler im System oder eine Manipulation der IT von außen könnte gravierende Störungen im Ablauf der Raumfahrtmission und nicht zuletzt hohe Kosten zur Folge haben.

Die geringsten Sicherheitsansprüche bestehen im Office-Netz. Nur innerhalb dieses Teils der Infrastruktur kann auf das Internet zugegriffen werden. Office-Programme und E-Mail dominieren dieses Segment.

LDAP sticht Active Directory

Die Vorgaben zur IT-Gestaltung werden beim Columbus-Projekt von der europäischen Raumfahrtbehörde ESA aufgestellt, in deren Auftrag das DLR das Columbus-Modul steuert. So sieht das ESA-Reglement zum Beispiel vor, dass die Benutzerauthentifizierung ausschließlich über einen zentralen LDAP-Server (Lightweight Directory Access Protocol) abläuft. Im hochkritischen Ops-Netz ist zudem die Anmeldung über Smartcards vorgeschrieben - eine Authentifizierungsmethode, die auch auf das Ops-Support-Netz ausgeweitet werden musste.

Eines der technischen Grundprobleme besteht darin, dass das Ops-Support-Netz eine gewachsene Windows-Domäne ist, wie Harald Stößner, Betreuer des Netzes, erläutert. In einer solchen Domäne will normalerweise der Microsoft-eigene Verzeichnisdienst Active Directory der Master sein. Beim DLR jedoch spielt laut ESA-Vorgabe LDAP diese Rolle, der Windows-Domain-Controller im Ops-Support-Subsystem muss also in die zweite Reihe treten. Dazu Stößner: "LDAP als führendes System mit den Windows-Bordmitteln einzubinden hätte einen enormen Aufwand und viel manuelles Eingreifen erfordert." Auch die Integration der Smartcards wäre sehr komplex gewesen.

Deshalb war eine Lösung gefragt, die drei Welten miteinander verbinden kann: das Active Directory der Windows-Domäne, die zentralen LDAP-Services und die Authentifizierung über Smartcards. Dazu Jürgen Fein, zuständig für die operationellen Abläufe im DLR-Kontrollzentrum: "Das bestehende Active Directory auszutauschen war keine sinnvolle Option. In der Windows-Domäne laufen zum Teil wichtige Tools der Nasa, die für Windows konzipiert wurden und diese Infrastruktur voraussetzen."

Wo es Anpassungbedarf gab

Auswahl und Evaluierung einer geeigneten Brücke zwischen den Systemwelten konnten sorgfältig angegangen werden, da die Vorgaben frühzeitig bekannt waren. "Viel Auswahl gab es nicht", erinnert sich Stößner, "wir haben nur ein Produkt gefunden, das allen unseren Anforderungen gerecht wird." Dabei handelte es sich um "SignOn Gate" von der Comtarsia IT Services GmbH, Wien.

Um die Lösung zu evaluieren, wurde zunächst ein Backup-Kontrollraum damit ausgestattet. Das DLR-Kontrollzentrum ist in der glücklichen Lage, neue IT-Lösungen während der Aus- und Weiterbildung der Flight Controller in praxisnahen Simulationen des Normalbetriebs testen zu können. Im Testbetrieb stellte sich heraus, wo die Lösung noch an den individuellen Bedarf anzupassen war.

Das betraf beispielsweise den Einsatz mehrerer PCs am selben Arbeitsplatz: Wegen der strikten Trennung der Netze arbeiten die Flight Controller der DLR jeweils mit drei Rechnern, von denen jeder einem Netz fest zugeordnet ist. Bei der Authentifizierung mittels Smartcard wird normalerweise ein Benutzer abgemeldet oder der PC gesperrt, sobald die Karte aus dem Lesegerät entfernt wird. Im Kontrollzentrum melden sich die Benutzer aber mit einer einzigen Karte an allen Maschinen an. Zudem dient sie als Zugangskontrolle zu den Flight-Control-Räumen und zu den Gebäuden.

Deshalb muss der Nutzer auch nach Entnahme der Karte im Ops-Support-Netz angemeldet bleiben. "Innerhalb unseres Sicherheitskontexts mit strengen, mehrstufigen Zugangskontrollen und physikalisch getrennten Netzen können wir das tolerieren", erläutert Fein, "im hochsicheren Ops-Netz, in dem die Steuerung des Columbus-Moduls läuft, wäre es hingegen nicht möglich." Der Softwareanbieter Comtarsia setzte die Funktionen für das Ops-Support Netz um.

Unterschiedliche Smartcard-Lösungen

Eine weitere Hürde war die heterogene Umgebung: Zwar werden im Ops- wie im Ops-Support-Netz Smartcards eingesetzt, doch kommen unterschiedliche Lösungen zur Authentifizierung zum Einsatz. Das hat sowohl historische als auch technische Gründe: Die intelligenten Karten kommen bereits seit einiger Zeit im hochsicheren Ops-Netz zum Einsatz, das auf Linux-Server und -Clients aufbaut. Die dort implementierte Software zur Benutzerauthentifizierung wäre nach Einschätzung von Fein und Stößner nur mit größter Mühe in die Windows-Domain zu übertragen gewesen.

Zudem ist das Smartcard-System der Linux-Infrastruktur nicht kompatibel zur Windows-Welt. Es ließ sich also nicht - jedenfalls nicht mit vertretbarem Technikaufwand - direkt auf die anderen Subsysteme ausweiten. Hier dient die Comtarsia-Lösung als Authentifizierungsschnittstelle zwischen den beiden Systemwelten.

Anmeldung in mehreren Stufen

Der operationelle Betrieb begann im Juni 2008. Heute erfolgt die Anmeldung am PC im Ops-Support-Subsystem in mehreren Schritten:

• Zunächst wird anhand der auf der Smartcard gespeicherten Daten und der PIN des Users ein Client-Zertifikat erstellt und der Benutzer damit gegen den zentralen LDAP-Server authentifiziert.

• Ist die Anmeldung am LDAP erfolgreich, wird ein Sign-on-Request an den "SingOn Gate"-Service von Comtarsia abgesetzt, der direkt am Windows-Domain-Controller installiert ist.

• Dieser Vorgang startet die automatische Benutzerverwaltung im Active Directory: Der User wird an der Windows-Domäne angemeldet; ist er dort noch nicht vorhanden, legt das System ihn mit den aus LDAP übernommenen Attributen neu an.

• Bei jeder Anmeldung sorgt das SignOn-Gate für ein Update der Benutzerinformationen, zum Beispiel der Gruppenmitgliedschaften, um die im führenden LDAP hinterlegten Daten mit denen des Active Directory zu synchronisieren.

• Damit die Anmeldung am Windows-Arbeitsplatz nicht über Smartcard und PIN ausgehebelt werden kann, kommen im Hintergrund zufällig erzeugte Passwörter zur Windows-Anmeldung zum Einsatz.

Der RoI war kein Thema

Der Return on Investment (RoI) spielte laut Fein und Stößner bei dem Projekt keine Rolle. "Es gab unseres Wissens keine Alternative, um die Anforderungen der ESA mit der bestehenden Infrastruktur zu erfüllen", konstatiert Fein. Positiv aus Sicht des DLR ist zudem, dass Comtarsia die notwendigen Funktionserweiterungen in künftige Versionen der Sign-on-Lösung integrieren will. So bleibt die Implementierung des DLR Release-fähig, Updates oder neue Versionen lassen sich ohne aufwändige Anpassungen einspielen. (qua)