Novell versucht den Spagat zwischen einer E-Business-Strategie einerseits und der Fokussierung auf seine Stärken andererseits. Dazu gehört auch das Wissen um den Aufbau sicherer Netzwerkinfrastrukturen. In diesem Bereich hat Novell in den letzten Monaten zwei neue Lösungen herausgebracht.
Eine davon ist Novell Single Sign-on, die andere sind die NMAS (Novell Modular Authentication Services). Hinzu kommen die PKI-Dienste, die mit dem NDS eDirectory 8.x ausgeliefert werden. Novell nutzt diese Technologien gemeinsam mit neuen Lösungen wie beispielsweise Novell iChain, einem E-Business-System, für das mittlerweile eine Reihe von Projekten insbesondere in Behörden laufen, bei denen besonders hohe Sicherheitsanforderungen gestellt werden.
Mit den Lösungsansätzen adressiert Novell zwei Bereiche: Auf der einen Seite geht es um eine Authentifizierung von Benutzern an unterschiedlichen Diensten im Netzwerk mit nur einem Kennwort. Andererseits soll aber auch erreicht werden, dass mehr Authentifizierungsmechanismen unterstützt werden und Zugriffsrechte auch abhängig vom verwendeten Mechanismus vergeben werden können. Damit wird beispielsweise ermöglicht, dass auf kritische Daten nur zugegriffen werden kann, wenn für die Anmeldung neben einem Kennwort auch ein biometrisches Verfahren verwendet wurde.
Mit Novell Single Sign-on (SSO) verspricht Novell, eines der drückendsten Probleme der IT zu lösen: die Notwendigkeit, dass jeder Benutzer sich eine Unzahl verschiedener Benutzernamen und Kennwörter für den Zugriff auf die von ihm genutzten Dienste merken muss.
An diesem Unterfangen haben sich in der Vergangenheit schon viele Anbieter versucht. Novell hat aber mit Single Sign-on zwei Vorteile. So gibt es eine vergleichsweise breite Unterstützung durch Drittanbieter, die Schnittstellen zu der Lösung entwickelt haben. Weiter wird in einem Bundle auch noch v-GO von Passlogix angeboten, das eine Reihe weiterer Anwendungen unterstützt.
Zu den Applikationen, die mit Novell Single Sign-on arbeiten, gehören unter anderem Lotus Notes, der Entrust eNtelligence Client, Microsoft Access und Host-Emulationsprodukte von Attachmate und WallData. Diese Liste wächst langsam, aber kontinuierlich.
Die Speicherung von Kennwörtern erfolgt bei Novell SSO im NDS eDirectory. Dort werden auch Änderungen unmittelbar abgelegt. Durch die Verwendung von NICI, das Kürzel steht für Novell International Cryptography Infrastructure, die mittlerweile auch eine 128-Bit-Verschlüsselung unterstützt, ist ein ausreichend sicherer Speicher gegeben. Grundsätzlich lassen sich auch andere Verschlüsselungstechnologien mit NICI integrieren.
Die Arbeitsweise von Novell SSO wird klar, wenn man sich die einzelnen Schritte betrachtet, die bei einer Anmeldung ausgeführt werden. Der Benutzer meldet sich zunächst an der NDS an. Dieser Schritt erfolgt typischerweise nach dem Start seines Computers. Er verwendet dafür sein NDS-Kennwort und den zugehörigen Benutzernamen. Das sollten auch die einzigen Informationen sein, die er für die Anmeldung benötigt.
Wenn der Benutzer nun eine Netzwerkanmeldung startet, wird dort ebenfalls eine Authentifizierung verlangt. Novell SSO holt das hierfür erforderliche Kennwort aus der NDS und übergibt es an die Anwendung, womit sich diese starten lässt. Die eigentlich von der Anmeldung verlangte Authentifizierung durch den Benutzer entfällt damit.
Allerdings wird hier auch schon deutlich, dass für das Zusammenspiel mit Novell SSO Anpassungen an der Client-Komponente der Anwendung erforderlich sind. Auf den Windows-Clients, auf denen das Programm derzeit unterstützt wird, muss für jede Anwendung eine spezielle DLL installiert werden, die den Anmeldeprozess verändert und mit Novell SSO integriert. Die Applikationshersteller müssen hier also mit Novell zusammenarbeiten, um solche Komponenten zu entwickeln.
Diese DLL fragt zunächst die NDS nach dem Kennwort für diese Anwendung ab. Ausserdem erkennt sie, wenn das betreffende Programm eine Änderung des Kennworts verlangt. Bei der ersten Nutzung einer Applikation mit der DLL für die Client-seitige SSO-Unterstützung werden einmalig noch der Benutzername und das Kennwort erfragt. Diese werden in der NDS gespeichert. Ab diesem Zeitpunkt erfolgt die Authentifizierung bei Anwendungen für den Benutzer transparent.
Novells Single Sign-on besteht aus einer Reihe von Komponenten. Ein zentraler Baustein ist die bereits angesprochene NICI, über welche die Verschlüsselungsfunktionen bereitgestellt werden. Seit der Lockerung der US-Exportrichtlinien Anfang 2000 ist hier eine 128-Bit-Verschlüsselung verfügbar. Mit Hilfe von NICI 1.3.1 und der NDS wird der sogenannte SecretStore realisiert. Dabei handelt es sich um eine NDS-Erweiterung, in der die Anmeldeinformationen für die von Single Sign-on unterstützten Anwendungen abgelegt werden. Hinzu kommt das NLM (NetWare Loadable Module) für Novell SSO, das auf dem Server ausgeführt wird.
Neben diesen Server-Komponenten gibt es den weiter oben bereits angesprochenen SSO-Client. Dieser erfragt Kennwortinformationen beim Server und arbeitet dabei über einen sicheren Kommunikationskanal.
Eine weitere wichtige Komponente ist der SD Key Server. Diese Funktion wird immer vom ersten Server übernommen, auf dem Novell SSO eingerichtet wird. Er erzeugt und verwaltet einen Schlüssel für den Schutz der Informationen im SecretStore.
Eine wichtige Funktion ist schliesslich noch die Enhanced Protection. Wenn diese aktiviert ist, werden die gespeicherten Authentifizierungsinformationen im SecretStore auch vor Administratoren wirksam geschützt. Wenn ein Systemverantwortlicher das Kennwort eines Benutzers ändert, kann er sich prinzipiell unter diesem Benutzerkonto anmelden. Bei Verwendung der Enhanced Protection wird das verhindert, weil der Zugriff mit dem neuen Kennwort auf die Informationen im SecretStore dann verweigert wird. Der erste Zugriff nach der Kennwortänderung ist nur mit dem zuletzt gültigen Kennwort, das vom Benutzer eingegeben wurde, möglich. Änderungen des NDS-Kennworts durch den Benutzer selbst sind davon nicht betroffen.
Da Novell SSO eine Reihe von Informationen in der NDS speichert, muss das Design gut geplant werden. Der SecretStore, über die Datei sss.nlm verwaltet, kann nur auf NetWare-5.x-Servern installiert, aber auch in gemischten Umgebungen mit NetWare-4.x-Servern genutzt werden. Wie ausgeführt, arbeitet der erste Server automatisch als SD-Server. Zu diesem müssen dann alle anderen Server während der Installation Kontakt aufnehmen, um den SSD Tree Key zu erhalten, der seinerseits für die Nutzung von NICI beim Zugriff auf den SecretStore benötigt wird.
Wenn sich Benutzer anmelden, muss wiederum eine Verbindung zu einem Server aufgebaut werden, der eine Master- oder Read/Write-Replik der Partition hält, in der das Benutzer-Objekt definiert ist und auf dem zudem sss.nlm geladen ist.
Dieser Aspekt ist es auch, der am meisten Auswirkungen auf die Netzlast haben kann. Wenn der Benutzer nicht an einem solchen Server authentifiziert ist, muss zunächst eine Liste von Servern ermittelt werden, die sowohl über eine Master- oder Read/Write-Replik der Partition verfügen als auch sss.nlm ausführen.
Das kann zu einer erheblichen Last im Netzwerk führen, wenn die Repliken der Partition über WAN-Verbindungen verteilt sind. Hinzu kommt, dass bei der Liste der Partitionen zunächst die Master-Partition und dann die Read/Write-Partitionen zurückgeliefert werden. Der Single-Sign-on-Client versucht dann, mit dem ersten Server in der Liste Kontakt aufzunehmen. Sobald in WAN-Umgebungen gearbeitet wird, ist es daher grundsätzlich sinnvoll, auf allen NDS-Servern, an denen eine Authentifizierung von Benutzernerfolgt, die mit Novell Single Sign-on arbeiten, auch sss.nlm zu installieren, womit sichergestellt wird, dass der Zugriff lokal geschieht. Ansonsten wird immer auf den Server mit der Master-Partition zugegriffen, soweit auf diesem sss.nlm ausgeführt wird. Wenn dieser Server aber nicht im lokalen Netzwerk steht, führt das zu erheblicher und unnötiger Last auf der WAN-Verbindung - eine mehrfache Installation von sss.nlm und die Replikation der Informationen im SecretStore sind hier die deutlich lasteffizientere Lösung.
Die stetige Entwicklung im Bereich der Authentifizierung ist insbesondere dadurch geprägt, dass gängige Verfahren für die Authentifizierung wie beispielsweise X.509 eingesetzt werden, daneben aber auch Kennwort-basierende Lösungen mehr und mehr ersetzt werden sollen.
Um eine Authentifizierung gegenüber den NDS über unterschiedliche Verfahren durchführen zu können, hat Novell die Novell Modular Authentication Services (NMAS) entwickelt. Diese werden von einer Reihe der führenden Unternehmen im Bereich der Sicherheit wie beispielsweise RSA Security, Schlumberger, Secure Computing oder Compaq unterstützt.
Die Grundidee der NMAS ist es, einen Rahmen bereitzustellen, in den sich andere Authentifizierungsverfahren integrieren lassen. Diese können alternativ zur bisher mit der NDS verwendeten Password Challenge Response eingesetzt werden. Dieses Verfahren ist allerdings unsicher, da der fahrlässige Umgang vieler Benutzer mit Benutzernamen und Kennwörtern Sicherheitslücken entstehen lässt. Zudem überfordert die Vielzahl von Systemen, an denen eine Anmeldung erfolgen muss, tendenziell die Benutzer und erhöht die Sicherheitsrisiken.
Das Problem von Lösungsansätzen am Markt ist die Integration mit bestehenden Systemen - eine Funktion, die von NMAS adressiert wird. Damit werden die Verfahren gleichermassen einfach nutzbar wie eine normale Anmeldung an der NDS.
NMAS unterstützt eine Reihe von Verfahren. Dazu zählen klassische Authentifizierungsverfahren unter Verwendung von Kennwörtern in Verbindung mit FTP, Telnet oder POP3 und die Unterstützung von SHA-1 und MD5. Natürlich lässt sich auch die Standard-Kennwort-Authentifizierung der NDS weiter nutzen. Schliesslich kann auch noch DES eingesetzt werden.
Die zweite Gruppe ist die Authentifizierung über physikalische Geräte. Dazu zählen insbesondere Smartcards. Die dafür erforderlichen digitalen Zertifikate nach dem X.509-Standard können mit dem Novell Certificate Server 2.0 erstellt werden. Auch Tokens werden unterstützt, die entweder nach einem Challenge/Response- oder einem zeitsynchronisierten Verfahren arbeiten. Diese Komponenten sind in vielen Unternehmen insbesondere für die Sicherung von Einwählverbindungen schon seit Jahren in Gebrauch.
Hauptsächlich der RSA ACE/Server ist hier von Bedeutung, der ebenfalls mit den NMAS integriert ist.
Schliesslich kommen mehr und mehr biometrische Verfahren auf. Dazu zählen beispielsweise Fingerabdrücke oder Merkmale der Augen. Auch in diesem Bereich gibt es Unterstützung für die NMAS, zumal die von diesen Systemen benötigten Authentifizierungsinformationen in der NDS abgelegt werden können. Durch die offene Struktur der NDS lassen sich die unterschiedlichen Anforderungen solcher Systeme einfach erfüllen.
Mit der NMAS Enterprise Edition, die lizenziert werden muss, werden dann im Vergleich zur Basisversion, die sich rein auf die Unterstützung unterschiedlicher Authentifizierungsverfahren beschränkt, zwei zusätzliche Funktionen unterstützt. Das ist zum einen die sogenannte Graded Authentication, bei der Zugriffsberechtigungen entsprechend der Stärke der Authentifizierung gesteuert werden können. Diese kann auf der Ebene von NDS-Partitionen und Volumes erfolgen.
Hier lassen sich bestimmte Kombinationen von Authentifizierungsverfahren definieren, die erforderlich sind, um auf Partitionen oder Volumes zuzugreifen. So kann beispielsweise definiert werden, dass auf bestimmte Volumes nur zugegriffen werden darf, wenn sowohl eine biometrische Authentifizierung als auch eine über ein Token erfolgt ist. Auf andere Volumes könnte dagegen nach jeder Form der Authentifizierung zugegriffen werden. Damit dieses Konzept aber funktioniert, kann es erforderlich werden, sowohl die Partitionierung der NDS grundlegend zu verändern als auch die Volumes umzustrukturieren, um jeweils Informationen mit gleichen Sicherheitsanforderungen innerhalb einer Partition oder Volumes zu halten.
Die zweite Funktion ist die Multi-factor Authentication, bei der mehrere Authentifizierungsschritte nacheinander durchgeführt werden müssen, wie oben am Beispiel der Kombination von biometrischen Verfahren und Tokens beschrieben. Diese mehrstufige Authentifizierung reduziert die Risiken, die beispielsweise dadurch entstehen können, dass ein Token in falsche Hände gerät, und ist auch die Basis dafür, dass sich eine Graded Authentication in sinnvoller Weise implementieren lässt.
Novell hat sich mit diesen Lösungen und dem NDS eDirectory als Basis auf seine Stärken besonnen. Im Bereich des Sicherheitsmanagements für Netzwerke hat das Unternehmen mittlerweile ein umfassendes Angebot aufgebaut. Hier gibt es derzeit kaum einen Anbieter, der über ein vergleichbares Leistungsspektrum verfügt - insbesondere auch deshalb, weil Novell in den Bereichen, die nicht selbst abgedeckt werden, gezielt Kooperationspartner gesucht und gefunden hat. Nicht zu unterschätzen ist in diesem Zusammenhang auch DirXML, mit dem eine Integration von Informationen aus unterschiedlichen Verzeichnisdiensten erfolgen kann.
