Planungshandbuch - Sichern von Wireless LANs mit Zertifikatsdiensten
Kapitel 3: Architektur der sicheren WLAN-Lösung
Auf dieser Seite
EinführungIm vorigen Kapitel wurden die Optionen für die WLAN-Absicherung betrachtet, und es wurde erläutert, warum für diese Lösung die auf 802.1X basierende WLAN-Authentifizierung mit Verwendung des Protokolls EAP-TLS gewählt wurde. In diesem Kapitel wird die Architektur der Lösung beschrieben. Anschließend wird auf der Grundlage der Entwurfskriterien für ein Beispielunternehmen ein logisches Modell abgeleitet. Diese Informationen können Sie als Ausgangspunkt für die Implementierung der Lösung verwenden. Das logische Modell basiert auf 802.1X-WLAN-Netzwerkhardware, der RADIUS-Authentifizierung (Remote Authentication Dial-In User Service) und einer Infrastruktur öffentlicher Schüssel (PKI). Voraussetzungen für das KapitelFür dieses Kapitel sollten Sie über Vorkenntnisse hinsichtlich der Konzepte für den Entwurf von IT-Infrastrukturen verfügen und mit den Hauptkomponenten vertraut sein, die Bestandteil des Entwurfs sind. Dabei handelt es sich um folgende: WLANs und Netzwerkkomponenten, RADIUS, der Active Directory® -Verzeichnisdienst und PKIs. Tiefergehende Kenntnisse zu diesen Elementen sind jedoch nicht erforderlich. KapitelüberblickMit diesem Kapitel werden die folgenden Ziele verfolgt:
In den nachfolgenden Kapiteln finden Sie ausführliche Informationen zum Entwurfsprozess für die einzelnen Hauptkomponenten innerhalb des logischen Modells (WLAN, RADIUS und PKI), die Ihnen beim Aufbau und Betrieb der Lösung helfen sollen. KonzeptentwurfWie Sie im vorherigen Kapitel erfahren haben, bringen Drahtlosnetzwerke eine Reihe ernstzunehmender Sicherheitsprobleme mit sich. Diese Sicherheitsprobleme werden durch Einsatz von WEP (Wired Equivalent Privacy) gemäß IEEE-Standard 802.11, wenn überhaupt, nur zum Teil beseitigt. Die in diesem Handbuch vorgeschlagene Lösung beschäftigt sich damit, wie die Sicherheit der WLAN-Kommunikation verbessert werden kann. Eine ideale Lösung für dieses Problem muss die folgenden Merkmale aufweisen:
Der 802.1X-Protokollstandard für Zugriffssteuerung erfüllt in Verbindung mit einer sicheren Authentifizierungsmethode wie EAP-TLS einige dieser Anforderungen. WEP bietet zwar auch eine relativ sichere Verschlüsselung des Netzwerkverkehrs, die Schlüsselverwaltung ist jedoch unzureichend. Die in 802.1X und EAP integrierten Methoden zur Verwaltung der WEP-Verschlüsselungsschlüssel sind wesentlich sicherer als die 802.11-Grundstandards. Der WPA-Standard (WiFi Protected Access) ist eine Sammlung von industriebasierten Standards, die (neben anderen Verbesserungen) 802.1X und EAP sowie ein standardisiertes Protokoll für die Schlüsselverwaltung umfasst, das TKIP (Temporal Key Integrity Protocol) genannt wird. Der WPA-Standard stellt einen großen Fortschritt bei der WLAN-Absicherung dar und wird von den meisten Analysten und Herstellern unterstützt. Hinweis: Keine der WPA-Verbesserungen löst die DoS-Sicherheitsprobleme von 802.11 und 802.1X. Diese DoS-Sicherheitsprobleme sind jedoch nicht so schwerwiegend wie andere WEP-Schwachstellen, und fast alle nachgewiesenen DoS-Angriffe verursachen lediglich vorübergehende Netzwerkunterbrechungen. Dennoch sehen einige Unternehmen in der Bedrohung durch DoS-Angriffe immer noch ein ernsthaftes Problem, das wahrscheinlich nicht vor der Veröffentlichung des IEEE 802.11i-Standards (für 2004 erwartet) gelöst werden kann. WPA wird zwar inzwischen weitreichend unterstützt, es gibt aber immer noch viele Geräte und Systeme, bei denen diese Unterstützung fehlt. Deshalb wurde die Lösung in diesem Handbuch so entwickelt, dass sie sowohl mit dynamischem WEP als auch mit WPA funktioniert. Die meisten Anbieter von Netzwerkhardware verkaufen Produkte, die 802.1X mit dynamischen WEP-Schlüsseln und WPA unterstützen. Bei dem in diesem Kapitel beschriebenen Entwurf sind die beiden Lösungsansätze austauschbar, d. h., wenn statt des einen Elements das andere Element verwendet wird, hat dies keinen entscheidenden Einfluss auf den Aufbau. Die folgende Abbildung enthält eine grafische Darstellung des Konzepts der Lösung (802.1X-EAP-TLS-Authentifizierung). Die Abbildung zeigt die folgenden vier Hauptkomponenten:
Die Ziffern in der Abbildung zeigen die Reihenfolge beim Netzwerkzugriff an. Dieser Ablauf wird im Folgenden ausführlicher beschrieben:
Die folgende Abbildung enthält eine genauere Darstellung des soeben beschriebenen Prozesses. Die Abbildung stellt die einzelnen Komponenten detaillierter dar. In späteren Abschnitten dieses Kapitels wird dieses Diagramm ausführlicher erläutert. Im Moment achten Sie bitte lediglich auf die folgenden Unterkomponenten des Authentifizierungsdienstes: die Zertifizierungsstelle (Certification Authority, CA), das Verzeichnis und den RADIUS-Server. Obwohl diese Unterkomponenten im Prinzip verhältnismäßig einfache Aufgaben ausführen, ist für das sichere, skalierbare, verwaltbare und zuverlässige Ausführen dieser Vorgänge eine recht ausgeklügelte Infrastruktur erforderlich. Der Großteil der dafür notwendigen Planung, Implementierung und Verwaltung wird in den nächsten Kapiteln dieses Handbuchs ausführlich beschrieben. Entwurfskriterien der LösungNachdem die Grundkonzepte der Lösung beschrieben wurden, können wir uns nun den wichtigsten Entwurfskriterien für die Lösung zuwenden. Diese Kriterien bilden die Richtlinien, anhand derer das Lösungskonzept in einen Entwurf übertragen werden kann, der auch tatsächlich implementierbar ist. Die Entwurfskriterien leiten sich aus den Anforderungen eines typischen Unternehmens ab, das für eine Implementierung dieser Lösung infrage kommt. In den folgenden Abschnitten werden ein solches Unternehmen und dessen wichtigste technische Voraussetzungen beschrieben. ZielunternehmenDie Beschreibung des Unternehmens in diesem Abschnitt verfolgt lediglich das Ziel, einen Kontext für die Entwurfskriterien bereitzustellen. Bei der Beurteilung der Lösung hinsichtlich ihrer Eignung für Ihr Unternehmen sollten Sie sich darauf konzentrieren, ob die Entwurfskriterien sinnvoll für Sie sind, und nicht darauf, ob Ihr Unternehmen dem in diesem Kapitel beschriebenen entspricht. So könnte das Zielunternehmen z. B. an einigen Standorten ein WLAN bereitgestellt haben, um Netzwerkinfrastrukturkosten zu minimieren und Mobilität und Produktivität der Mitarbeiter zu steigern. Das Unternehmen ist sich genau der Wichtigkeit von Sicherheitsmaßnahmen bewusst und hat bereits eine Reihe von Technologien eingesetzt, um seine IT-Sicherheit zu erhöhen. Dazu gehören die Bereitstellung einer Domänenauthentifizierung, Internetfirewalls, Virenschutzprogramme und eine RAS- bzw. VPN-Lösung. Darüber hinaus plant das Unternehmen, auf längere Sicht eine Reihe anderer Hochsicherheitsanwendungen einzusetzen, wie z. B. Dateiverschlüsselung und sichere E-Mail. Das logische und physische Netzwerklayout dieses Unternehmens könnte, vereinfacht dargestellt, in etwa wie folgt aussehen:  Abbildung 3.3: Schematische Darstellung des physischen Netzwerklayouts des Zielunternehmens In der Abbildung sind zwar jeweils nur eine große und eine kleine Zweigstelle dargestellt, in der Praxis können aber mehrere Zweigstellen vorhanden sein. Aus Gründen der Übersichtlichkeit werden in der Abbildung nur wenige Server und Clients gezeigt. Diese geringe Anzahl an Hosts ist für ein typisches Unternehmen nicht unbedingt repräsentativ. Mit gewissen Einschränkungen gilt aber, dass die Größe des Zielunternehmens nur relativ wenig Einfluss auf die Entwurfskriterien für die Lösung hat. Bei kleineren Unternehmen verfügt die Hauptverwaltung vielleicht über ein paar hundert Mitarbeiter, die mit Zweigstellen zusammenarbeiten, in denen die Mitarbeiterzahl jeweils im zweistelligen Bereich liegt. Bei größeren Unternehmen arbeiten am Hauptsitz möglicherweise ein paar tausend Mitarbeiter, und in den Zweigstellen sind jeweils mehrere hundert Mitarbeiter tätig. Unabhängig von ihrer Größe besitzen die Unternehmen in der Regel auch kleinere Büros mit einer geringen Mitarbeiterzahl. UnternehmensanforderungenDie folgenden Anforderungen sind typisch für das in diesem Szenario dargestellte Unternehmen:
Darüber hinaus gibt es normalerweise noch eine Reihe anderer, mehr technischer Anforderungen:
Entwurfskriterien der LösungAus diesen Anforderungen lassen sich die in der folgenden Tabelle gezeigten Kriterien zur Unterstützung des Lösungsentwurfs ableiten. Tabelle 3.1: Entwurfskriterien für die Lösung
Logischer LösungsentwurfDieser Abschnitt beschreibt den logischen und logisch-physischen Lösungsentwurf. Dies umfasst die Spezifikation und Anordnung der eigentlichen Komponenten, ohne dass dabei Details zum physischen Entwurf, wie etwa die Spezifikation der Serverhardware, berücksichtigt werden. Prüfung des KonzeptentwurfsDieser Abschnitt beschäftigt sich anhand der folgenden Abbildung, die bereits weiter oben in diesem Kapitel zu finden ist, mit dem Thema, wie sich die einzelnen Komponenten in den Gesamtentwurf eingliedern. Logisches ModellIn der Abbildung oben wurden die logischen Komponenten unterteilt, um den Prozess für den Zugriff auf das WLAN besser verständlich zu machen. Zur Vereinfachung von Bereitstellung und Verwaltung ist es jedoch sinnvoll, die Komponenten geringfügig anders zu unterteilen. Die Gruppierung der Komponenten ermöglicht die modulare Betrachtung des gesamten Entwurfs und damit eine größtmögliche Wiederverwendbarkeit dieser Komponenten. So wäre es z. B. möglich, die PKI-Komponente nur mit dem Ziel zu implementieren, die WLAN-Benutzer zu authentifizieren. Eine solche Verwendung würde jedoch möglicherweise die Wiederverwendbarkeit der PKI-Komponente für andere Anwendungen einschränken. Auch beim Entwerfen der RADIUS-Komponente für die Lösung sollte bedacht werden, welche anderen Anwendungen zukünftig hinzukommen könnten, die von dieser Komponente unterstützt werden müssen. Die IT-Dienste im Entwurf sind in die folgenden Kategorien unterteilt:
Diese letzte Komponente umfasst ein Verzeichnis und unterstützende Netzwerkdienste. Zu diesen Diensten gehören IT-Dienste, die in der Regel bereits im Unternehmen vorhanden sind, mit denen die Lösung aber in irgendeiner Weise interagiert. Logisch-physische EbeneAuf logisch-physischer Ebene wird aus dem Modell jetzt deutlich, wie diese Komponenten als physische Server implementiert, miteinander verbunden und auf die verschiedenen Standorte des Zielunternehmens verteilt werden. Die Anzahl der in der folgenden Abbildung enthaltenen Server ist aber lediglich eine allgemeine Angabe. Die endgültige Festlegung von Anzahl und Platzierung der Server wird in den nächsten Kapiteln dieses Handbuchs erörtert, die sich mit der Planung beschäftigen. HauptverwaltungDie folgende Abbildung zeigt die Serverimplementierung in der Hauptverwaltung. Die ersten drei Komponenten stellen neue Server bzw. zu erwerbende Komponenten dar. Die Infrastrukturdienstkomponenten sind in den meisten Unternehmen normalerweise bereits in irgendeiner Form vorhanden. Wenn Ihr Unternehmen bereits eine 802.1X-fähige WLAN-Ausrüstung besitzt, ist möglicherweise auch die WLAN-Komponente schon vorhanden. Großes Regionalbüro/ZweigstelleDie folgende Abbildung zeigt das physische Layout für eine größere Zweigstelle. Es unterscheidet sich vom Layout einer kleinen Zweigstelle durch das Vorhandensein eines lokalen Domänencontrollers vor Ort. Für die Zweigniederlassung wird ein einzelner IAS-Server bereitgestellt. Obwohl der IAS-Server hier als separater Server dargestellt ist, kann dieser Dienst auch vom Domänencontroller ausgeführt werden. Hinweis: Wenn die WAN-Verbindung zur Hauptverwaltung zuverlässig ist (d. h. wenn redundante Netzwerkverbindungen vorhanden sind), und diese Verbindung nicht besonders überlastet ist, kann die große Zweigstelle statt ihrer eigenen die RADIUS-Dienste der Hauptverwaltung nutzen. Diese Möglichkeit wird detaillierter in Kapitel 5, "Entwerfen der RADIUS-Infrastruktur für die WLAN-Absicherung" besprochen. Alle anderen Dienste (zum Beispiel die CAs) werden über die Hauptverwaltung bereitgestellt. Kleine ZweigstelleEine kleine Zweigstelle verfügt möglicherweise über eine gewisse IT-Infrastruktur, wie z. B. einen Dateiserver und Drucker, eine Authentifizierungsinfrastruktur ist in der Regel jedoch nicht vorhanden. Einige Unternehmen sind der Ansicht, dass diese Zweigstellen keinerlei WLAN-Dienste benötigen bzw. solche Dienste dort nicht gerechtfertigt sind. Andere Unternehmen hingegen, die temporäre Zweigstellen unterhalten, empfinden es als angenehm, keine Netzwerkkabel verlegen und verwalten zu müssen. Wenn WLAN-Dienste in kleinen Zweigstellen ohne lokalen Domänencontroller benötigt werden, greifen die WLAN-APs auf den IAS-Server und die Infrastruktur zur Domänenauthentifizierung in der Hauptverwaltung zurück. Das Hauptproblem bei dieser Vorgehensweise liegt darin, dass die gesamte WLAN-Konnektivität verloren geht, falls die WAN-Verbindung zur Hauptverwaltung ausfällt. Für dieses Szenario gibt es zwar keine einfache Lösung, Sie können diesem Problem jedoch (verbunden mit entsprechenden Kosten) entgegentreten, indem Sie WAN-Redundanz bereitstellen oder lokale Domänencontroller einsetzen. Wenn die Bereitstellung von WAN-Redundanz oder die Anschaffung lokaler Domänencontroller in den kleinen Niederlassungen Ihrem Unternehmen zu teuer ist, gibt es noch die Alternative, mithilfe des PSK-Modus von WPA isolierte WLAN-APs bereitzustellen. Alle Wi-Fi-zertifizierten WLAN-APs unterstützen mittlerweile WPA. Diese Alternative ist zwar viel sicherer als die statische WEP-Verschlüsselung, ist aber mit einem zusätzlichen Verwaltungsaufwand verbunden. SkalierungsstrategieEines der wichtigsten Entwurfskriterien ist die Sicherstellung der Skalierbarkeit des Entwurfs. Die Lösung muss viele verschiedene Implementierungsgrößen zu jeweils vertretbaren Kosten unterstützen. Beispielsweise muss eine Implementierung für 500 Benutzer proportional weniger kosten als eine Implementierung für 5.000 Benutzer. Auch die Komplexität der Implementierung und Verwaltung der Lösung muss für die Unternehmen in einem angemessenen Rahmen bleiben. Großes UnternehmenIn der folgenden Abbildung ist dargestellt, wie der Entwurf skaliert werden kann, um eine große Zahl von Benutzern in einer Hauptverwaltung und in großen Zweigstellen zu versorgen. Möglicherweise bedienen die IAS-Server dabei auch andere Netzwerkanwendungen, wie z. B. VPNs. Weitere Informationen zu diesem Thema finden Sie im Abschnitt "Erweitern des Entwurfs" weiter unten in diesem Kapitel. Diese Überlegung hat möglicherweise auch Einfluss auf das konkrete Layout und die Anzahl der Server. Die zusätzlichen IAS-Server in der folgenden Abbildung dienen lediglich zur Illustration. Alle zusätzlich für die skalierte Version der Lösung benötigten Server sind grau dargestellt. Kleines UnternehmenBei kleinen Unternehmen kann die Lösung mit verhältnismäßig wenig neuer Hardware und Software implementiert werden. Dies wird hauptsächlich durch Ausführen von IAS auf vorhandenen Domänencontrollern erreicht. Diese Konfiguration wurde von der IAS-Produktgruppe bei Microsoft gründlich getestet und wird für viele Szenarien empfohlen. Die folgende Abbildung veranschaulicht diese Version des Entwurfs.  Abbildung 3.10: Skalierte Version der Lösung für ein kleines Unternehmen Die RADIUS-Komponente wird hier zwar immer noch logisch getrennt dargestellt (damit das Layout besser mit dem Layout in der vorhergehenden Abbildung verglichen werden kann), die eigentliche Implementierung der Komponente als Dienst erfolgt jedoch auf den schon vorhandenen Domänencontrollern. Die einzigen Server, die in dieser Version der Lösung benötigt werden, sind die CAs, die im PKI-Bereich des Lösungsentwurfs residieren. Erweitern des EntwurfsEin weiteres wesentliches Entwurfskriterium der Lösung ist die Wiederverwendbarkeit von Komponenten in zukünftigen Anwendungen. Sowohl die RADIUS-Komponente als auch die PKI-Komponente können für Authentifizierung und andere Sicherheitsdienste bei zahlreichen Anwendungen wieder verwendet werden. Andere NetzwerkzugriffsdiensteDer in dieser Lösung verwendete RADIUS-Entwurf kann die Authentifizierungs-, Autorisierungs- und Kontoführungsdienste für andere Netzwerkzugriffsserver übernehmen, beispielsweise die Authentifizierung in drahtgebundenen Netzwerken mit 802.1X sowie VPN- und RAS-Authentifizierung. Drahtgebundene Netzwerkauthentifizierung mit 802.1XDie einfachste Anwendung, die keine Änderung des WLAN-RADIUS-Grundentwurfs erfordert, ist die Authentifizierung mit 802.1X in drahtgebundenen Netzwerken. Für Unternehmen, die über eine weit verbreitete drahtgebundene Netzwerkinfrastruktur verfügen, ist es möglicherweise schwierig, die nicht autorisierte Verwendung des Firmennetzwerks zu steuern. So ist es beispielsweise oft nicht einfach, Besucher am Anschließen von Laptops oder Mitarbeiter am Hinzufügen nicht autorisierter Computer zum Netzwerk zu hindern. Einige Bereiche des Netzwerks, z. B. Datenzentren, sind möglicherweise als Hochsicherheitszonen eingestuft. In diesen Hochsicherheitszonen sollten nur autorisierte Geräte zugelassen werden selbst wenn dies zum Ausschluss von Mitarbeitern mit Firmencomputern führt. In der folgenden Abbildung wird dargestellt, wie eine Lösung für den Zugriff auf drahtgebundene Netzwerke in den Entwurf integriert werden kann: Der schwarz umrandete Bereich enthält die 802.1X-Komponenten für das drahtgebundene Netzwerk, die anderen Bereiche des Layouts beinhalten die jeweiligen Dienste, die in der vorherigen Abbildung des Entwurfs dargestellt sind.  Abbildung 3.11: Verwendung der 802.1X-Authentifizierung für drahtgebundene Netzwerke Netzwerke, die 802.1X-Switches verwenden, spielen die gleiche Rolle wie die WLAN-APs in der Kernlösung. Darüber hinaus können diese Netzwerke dieselbe RADIUS-Infrastruktur zum Authentifizieren der Clients und zur selektiven Autorisierung des Zugriffs auf das entsprechende Netzwerksegment verwenden. Diese Version der Lösung besitzt den eindeutigen Vorteil, dass die Kontenverwaltung im Firmenverzeichnis zentralisiert wird, während die Netzwerkzugriffsrichtlinien weiterhin unter der Kontrolle des Netzwerksicherheitsadministrators bleiben. VPN- und RAS-DFÜ-AuthentifizierungEin weiterer Netzwerkzugriffsdienst, der die RADIUS-Komponenten verwenden könnte, ist VPN- und RAS-DFÜ. Insbesondere in größeren Unternehmen ist es wahrscheinlich, dass einige Komponenten zum derzeitigen Entwurf hinzugefügt werden müssen, z. B. RADIUS-Proxies. Die folgende Abbildung zeigt, wie die erweiterte Lösung aussehen könnte.  Abbildung 3.12: Erweitern der RADIUS-Komponente zur Unterstützung eines VPN Die VPN-Server in dieser Lösung spielen die gleiche NAS-Rolle wie die WLAN-APs im Hauptentwurf: Sie leiten die Authentifizierungsanforderungen der Clients an die RADIUS-Infrastruktur weiter. Es ist zwar möglich, die RADIUS-Anforderungen direkt an die internen IAS-Server zu übergeben, sicherer ist es aber, eine RADIUS-Proxyschicht zu verwenden, die die Anforderungen an die internen IAS-Server weiterleitet. Bei dieser Lösung werden die Vorteile Verwendung der vorhandenen Infrastruktur und Zentralisierung der Kontenverwaltung miteinander verknüpft, während die Netzwerkzugriffsrichtlinien weiterhin unter der Kontrolle des Netzwerksicherheitsadministrators bleiben. Weitere Verbesserungen, z. B. das Erzwingen einer Benutzerauthentifizierung auf Smartcard-Basis, führen zu einer zusätzlichen Stärkung der Sicherheit. Microsoft verwendet für seine eigenen internen Mitarbeiter bei der Herstellung einer sicheren Verbindung zum Unternehmensnetzwerk eine sehr ähnliche Konfiguration. Remotezugriff per DFÜ funktioniert ähnlich. Hierbei wird statt der VPN-Funktionalität die DFÜ-Serverfunktion des Routing- und RAS-Dienstes von Windows verwendet. Die Verwendung von RADIUS (genauer gesagt IAS) in diesem Szenario bietet einen weiteren Vorteil: Es können Quarantänerichtlinien eingesetzt werden. Dabei werden der Routing- und RAS-Dienst in Microsoft Windows Server 2003 und der Verbindungs-Manager (der erweiterte RAS-Client in Windows) verwendet, um auf der Basis des Sicherheitsstatus des Clientcomputers zu bestimmen, ob der Zugriff zugelassen oder abgelehnt wird. Bei dieser Konfiguration kann IAS überprüfen, ob der Client beim Herstellen der Verbindung zum Netzwerk bestimmte Anforderungen erfüllt. So kann z. B. geprüft werden, ob der Client aktuelle Antivirensoftware besitzt oder ein betriebsintern vorgeschriebener Build des Betriebssystems ausgeführt wird. Wenn der Client diese Prüfungen nicht besteht, verweigert der RADIUS-Server ihm den Zugriff auf das Netzwerk. Auf diese Weise können sogar ordnungsgemäß authentifizierte Benutzer und Computer zurückgewiesen werden, falls sie eine mögliche Sicherheitsbedrohung für das Unternehmensnetzwerk darstellen. PKI-AnwendungsbereicheDa den Kriterien der Wiederverwendung und Erweiterbarkeit eine hohe Priorität zukommt, wurde die PKI-Komponente unter dem Gesichtspunkt entworfen, dass sie zukünftig möglicherweise für mehrere unterschiedliche Sicherheitsanwendungen verwendet werden kann. Wie im nächsten Kapitel erläutert wird, ist der PKI-Entwurf daher das Ergebnis einer Doppelstrategie: Zum einen sollen im Rahmen der Erarbeitung einer sicheren WLAN-Lösung die Kosten und die Komplexität so gering wie möglich gehalten werden, während andererseits eine ausreichende Flexibilität gewahrt werden soll, um die Komponente als Grundlage für zukünftige Anwendungsbereiche wiederverwenden zu können. In der folgenden Abbildung sind einige Anwendungsbereiche dargestellt, die die PKI-Komponente neben der sicheren WLAN-Anwendung unterstützen könnte. Bei einigen handelt es sich um relativ einfache Anwendungen, bei denen die in dieser Lösung entwickelte PKI mit nur geringfügigen oder gar keinen Änderungen im Vergleich zum Hauptentwurf verwendet werden kann. Andere dagegen, wie z. B. sichere E-Mail und Smartcard-Anmeldung, sind komplexer und erfordern mit hoher Wahrscheinlichkeit sorgfältigere Überlegungen und eine gewisse Erweiterung des PKI-Entwurfs. Erneute Beurteilung der EntwurfskriterienBevor dieses Kapitel abgeschlossen wird, möchten wir noch einmal die Liste der Entwurfskriterien für die Lösung durchgehen und prüfen, inwieweit der vorgeschlagene Entwurf den gesetzten Zielen gerecht wird. Die Überlegungen dazu sind in der folgenden Liste zusammengefasst. Auf viele dieser Punkte wird jedoch erst in den nachfolgenden Kapiteln ausführlich eingegangen.
ZusammenfassungIn diesem Kapitel wurde der konzeptionelle Entwurf einer sicheren WLAN-Netzwerklösung untersucht, die das 802.1X-Protokoll und EAP-TLS verwendet. Die Schlüsselkomponenten der Lösung wurden aus der Sicht der WLAN-Architektur erläutert. Anschließend wurde in Umrissen ein Zielunternehmen für diese Lösung beschrieben, und es wurden die Entwurfskriterien genannt, auf denen die Lösung aufbauen sollte. Anhand der Entwurfskriterien wurde das Konzept der Lösung in einen logischen Lösungsentwurf übertragen. Dazu gehörte die Prüfung der Implementierungsoptionen, mit denen die Lösung für Unternehmen unterschiedlicher Größe mit verschiedenen Anforderungen skaliert werden kann. Außerdem wurde untersucht, wie der Grundentwurf so erweitert werden kann, dass auch andere Netzwerkzugriffs- und Sicherheitsanwendungen unterstützt werden. Schließlich wurde geprüft, inwieweit die Funktionen des vorgeschlagenen Entwurfs den wichtigsten Entwurfskriterien gerecht werden. Diese Überprüfung bildet den Ausgangspunkt für die verbleibenden Kapitel des Planungshandbuchs. Die folgenden drei Kapitel befassen sich detailliert mit der Gestaltung der einzelnen Hauptkomponenten der Lösungsarchitektur: PKI, RADIUS-Infrastruktur und Entwurf zur WLAN-Absicherung.
|
In diesem Beitrag
|
