6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk

196 6 VPNs im Umfeld von Firewalls Policy Server Der SecureClient benötigt im Gegensatz zu SecuRemote gatewayseitig den lizenzpflichtigen Check Point Policy Server. Der Policy Server wird auf dem Filtermodul mitinstalliert (siehe Abschnitt»Installation der Check Point FireWall-1«, S. 106) und ist vor allem für folgende Aufgaben zuständig: Vorhalten der Desktop Policy Die Desktop Policy ist die Regelbasis für die Personal-Firewall des SecureClients. Sie wird mit dem Check Point SmartDashboard zentral konfiguriert und anschließend vom Management-Modul auf den Policy Server geschoben. Zuweisung der Desktop Policy an den SecureClient Sobald sich der SecureClient in den Policy Server einloggt, weist dieser dem SecureClient die aktuelle Desktop Policy zu. Empfangen und Verarbeiten der Logdaten des SecureClients 6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 6.3.1 Ausgangssituation Der Ausgangszustand unseres Unternehmensnetzwerks ist in Abb. 4 37 wiedergegeben. Das interne Netz wird vor dem Internet über eine zweistufige Firewall- Architektur abgesichert, die aus einer Check Point FireWall-1 und einer Cisco PIX besteht. Der ursprünglich vorhandene Einwahlrouter router_ras wurde aus den in Abschnitt»Modifikation der Ausgangssituation«, S. 135, genannten Gründen abgeschafft. Stattdessen realisieren wir nun den Remote-Zugriff für Mitarbeiter und Fremdfirmenmitarbeiter über das Internet unter Verwendung von VPN-Technologie. Beide Firewall-Produkte, Check Point FireWall-1/VPN-1 und Cisco PIX, unterstützen Remote-Access-VPNs, und die Hersteller bieten entsprechende Client-Software an. Es stellt sich daher die Frage, ob wir den Tunnel an der externen oder an der internen Firewall enden lassen. Die Entscheidung fällt zugunsten der externen Firewall aus, da auf diese Weise ein höheres Sicherheitsniveau erreicht werden kann. Im Falle einer Fehlkonfiguration auf der externen Firewall, die zum Beispiel allen Remote-Usern, auch den Fremdfirmenmitarbeitern, den uneingeschränkten Zugriff auf sämtliche internen Ressourcen erlaubt, existiert mit einer korrekt konfigurierten internen Firewall immer noch eine Barriere, die den uneingeschränkten Zugriff unterbinden kann. Würde der Tunnel an der internen Firewall terminieren und derselbe Konfigurationsfehler gemacht werden, hätten Remote-User uneingeschränkten

6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 197 Zugriff auf alle internen Ressourcen, was insbesondere im Fall der Fremdfirmenmitarbeiter nicht erwünscht ist. Damit sich die Anwender stark authentifizieren können, werden sie mit Hardware-Tokens (siehe Abschnitt»Authentifizierung«, S. 58) zur Erzeugung von Einmalpasswörtern ausgestattet. Die Einmalpasswörter werden von SecuRemote bzw. vom SecureClient zusammen mit dem Benutzernamen an die Firewall übermittelt. Die Firewall kontaktiert anschließend über das Radius-Protokoll den Authentifizierungsserver, der die Credentials überprüft und das Ergebnis der Firewall übermittelt. Ein geeigneter Platzierungsort für den Authentifizierungsserver ist die Management-DMZ, in der sich auch die Management-Station der Fire- Wall-1 befindet (siehe Abb. 4 3). Dem Authentifizierungsserver weisen wir die IP-Adresse 10.10.60.6 zu. Mit dem Check Point SmartDashboard muss ein entsprechendes Server-Objekt vom Typ Radius angelegt werden. 6.3.2 Konfiguration der Check Point FireWall-1/VPN-1 Nachdem wir uns entschieden haben, den VPN-Tunnel an der externen Firewall fw_ext enden zu lassen, beginnen wir nun mit den erforderlichen Konfigurationsarbeiten für das Remote-Access-VPN. In diesem Abschnitt behandeln wir die Gateway-Seite. Abschnitt»Clientseitige Konfiguration«, S. 209, geht auf die Installations- und Konfigurationsarbeiten ein, die auf der Client-Seite (Laptop, Heimarbeitsplatz) nötig sind. Installationstätigkeiten Auf fw_ext fallen für das Remote-Access-VPN keine Installationstätigkeiten mehr an. Den Policy Server haben wir von Anfang an mitinstalliert (siehe Abschnitt»Installation der Check Point FireWall-1«, S. 106); daher können wir umgehend mit der Konfiguration beginnen. Globale Eigenschaften Zusätzlich zu den in Abschnitt»Konfiguration der Check Point FireWall-1«, S. 108, bereits konfigurierten globalen Eigenschaften müssen wir für das Remote- Access-VPN unter GLOBAL PROPERTIES folgende weitere Einstellungen vornehmen: Aktivierung von IP Pool NAT Unter NAT muss IP Pool NAT aktiviert werden (siehe Abb. 6 8), um zu vermeiden, dass im internen Netz die offiziellen, vom jeweiligen ISP zugewiesenen IP-Adressen auftauchen. IP Pool NAT wurde in Abschnitt»Check Point VPN-1 und SecuRemote/SecureClient«, S. 193, beschrieben.

198 6 VPNs im Umfeld von Firewalls Abb. 6 8 Aktivierung von IP Pool NAT Globale SecuRemote/SecureClient-Eigenschaften Abb. 6 9 dokumentiert die globalen Eigenschaften für den VPN-Client, die wir für unser Unternehmensnetzwerk ausgewählt haben. Die unter TOPOLOGY UPDATE vorgenommenen Einstellungen bewirken, dass dem Client Änderungen an der Topologie automatisch mitgeteilt werden, d.h. Änderungen an der Menge von IP-Adressen, zu denen der VPN- Client verschlüsselte Verbindungen hin aufbauen darf. Abb. 6 9 SecuRemote/Secure-Client-Eigenschaften

6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 199 Der AUTHENTICATION TIMEOUT definiert, wie lange ein authentifizierter Remote-User mit der Site kommunizieren darf. Nach Ablauf dieser Zeitspanne wird er von SecuRemote bzw. vom SecureClient erneut zur Authentifizierung aufgefordert. Unter ADDITIONAL PROPERTIES wurde zum einen erzwungen, dass DNS-Anfragen an DNS-Server innerhalb der VPN Domain verschlüsselt werden. Aus Performance-Gründen könnte es eventuell sinnvoll sein, die Verschlüsselung von DNS-Anfragen zu unterbinden. Zum anderen wird mit der Aktivierung von ENABLE BACK CONNECTIONS erreicht, dass Rückverbindungen vom Gateway zum Client (zum Beispiel bei ftp die Datenverbindung) ebenfalls verschlüsselt werden. VPN-Parameter Für SecuRemote bzw. für den SecureClient wurden unter REMOTE ACCESS/VPN ADVANCED die in Abb. 6 10 abgedruckten Parameter für Verschlüsselung, Datenintegrität und IKE eingestellt. Abb. 6 10 VPN-Eigenschaften

200 6 VPNs im Umfeld von Firewalls Zusätzlich ist unter REMOTE ACCESS/VPN BASIC die Auswahl des HYBRID MODE als Authentifizierungsmethode für IKE entscheidend. Nur so ist die im folgenden Abschnitt beschriebene Radius-Authentifizierung für Remote-User überhaupt möglich. Enforcement-Modul Die in Abschnitt»Konfiguration der Check Point FireWall-1«, S. 108, vorgenommene Konfiguration des Enforcement-Moduls muss wie folgt erweitert werden: General Properties Unter CHECK POINT PRODUCTS müssen zusätzlich VPN und SECUREC- LIENT POLICY SERVER ausgewählt werden (vgl. Abb. 4 10). Topology Zusätzlich zu den Interfaces und Anti-Spoofing wird unter TOPOLOGY auch die VPN Domain konfiguriert. In Abschnitt»Check Point VPN-1 und SecuRemote/SecureClient«, S. 193, wurde die VPN Domain als die Menge der IP-Adressen definiert, mit denen der SecureClient verschlüsselt kommunizieren kann. Mit der Einstellung aus Abb. 6 11 umfasst die VPN Domain alle IP-Adressen, die bei der Interface-Definition von hme0, qfe1 und qfe2 unter IP ADDRESSES BEHIND INTERFACE (siehe Abb. 4 11) jeweils angegeben wurden. Konkret sind dies das Netz 10.10.60.0/28 (hme0), das Netz 140.252.90.184/29 (qfe1) sowie alle Objekte, die in der Gruppe Interne_Netze enthalten sind (qfe2). qfe0 ist das externe Interface und ist für die VPN Domain folglich unerheblich. Abb. 6 11 Spezifikation der VPN Domain NAT Nachdem in den GLOBAL PROPERTIES IP Pool NAT generell aktiviert wurde, muss beim Enforcement-Modul unter NAT der konkrete IP-Pool festgelegt werden. Als IP-Pool wählen wir für unser Firmennetzwerk das Objekt REMOTEUSER (10.10.10.0/24) aus. Sobald ein Remote-User über das VPN die erste Verbindung ins interne Netz aufbaut, wählt die Firewall eine freie IP-Adresse aus dem Pool 10.10.10.0/24 aus und übersetzt die offizielle Quell-Adresse aller Pakete von diesem User in die private Adresse. Die IP-Adresse wird dem Pool zurückgegeben, nachdem die Firewall 60 Minuten lang keine Pakete mehr von diesem Benutzer empfangen hat (siehe Abb. 6 12).

6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 201 Abb. 6 12 Konfiguration von IP Pool NAT Authentication Unter AUTHENTICATION werden die Authentifizierungsmethoden ausgewählt, die das Enforcement-Modul unterstützen soll, um VPN-Benutzer zu authentifizieren. Voraussetzung für die Verwendung einer dieser Methoden zur Authentifizierung von IPSec-Tunneln ist die weiter oben beschriebene Aktivierung des Hybrid Mode in den Global Properties. Da unsere Firewall den Authentifizierungsserver über Radius abfragt, wählen wir ausschließlich RADIUS aus (siehe Abb. 6 13). Unter AUTHENTICATION wird außerdem festgelegt, welche Benutzer sich in den Policy Server einloggen dürfen. In unserem Fall ist das die Gruppe RemoteAccessUsers (siehe auch den Abschnitt»Benutzerverwaltung«weiter unten). Abb. 6 13 Auswahl der Authentifizierungsmethoden, die das Gateway unterstützt

202 6 VPNs im Umfeld von Firewalls Split DNS Ein interessanter Aspekt im Zusammenhang mit Remote-Access-VPNs ist die Namensauflösung über DNS. Bei der Einwahl ins Internet wird dem Rechner des Remote-Users von seinem ISP neben der IP-Adresse auch ein DNS-Server zugewiesen, damit Namen im Internet aufgelöst werden können. Nach dem Aufbau eines Tunnels zur Firma besteht aber auch die Notwendigkeit, interne Namen auflösen zu können. Bei herkömmlichen Einwahllösungen (Dial-In direkt in die Firma) oder bei einem L2TP-Tunnel kann dem Remote-PC über PPP ein interner DNS-Server zugewiesen werden. Bei reinen IPSec-Tunneln besteht diese Möglichkeit nicht, da PPP nur zwischen dem Remote-PC und dem Einwahlrouter des ISP gesprochen wird. Check Point löst diese Problematik durch so genannte SecuRemote DNS-Server. Hierbei handelt es sich um ein spezielles Server-Objekt, das neben der IP- Adresse des internen DNS-Servers auch die intern verwendete(n) DNS-Domäne(n), zum Beispiel».firma-intern.com«, beinhaltet. Diese Informationen sind Bestandteil der Topologie, die sich SecuRemote bzw. der SecureClient vom Enforcement- Modul herunterlädt. Dadurch ist das Kernel-Modul in der Lage, DNS-Anfragen zur Auflösung interner Hostnamen (zum Beispiel»intranet.firma-intern.com«) über den Tunnel an den internen DNS-Server zu leiten. Für alle anderen Domänen wird weiterhin der vom ISP zugewiesene DNS-Server verwendet. Abb. 6 14 Definition eines SecuRemote DNS-Servers (1) In unserem Firmennetzwerk sind für die Definition des SecuRemote DNS-Servers folgende Schritte erforderlich: Zunächst definieren wir den internen DNS-Server als Objekt vom Typ Host (Objektname: DNS_int, IP-Adresse 10.10.100.40).

6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 203 Dieses Objekt verwenden wir in der Definition des SecuRemote DNS-Servers (siehe Abb. 6 14). Unter DOMAINS konfigurieren wir die intern verwendete DNS-Domäne (siehe Abb. 6 15). Abb. 6 15 Definition eines SecuRemote DNS-Servers (2) Benutzerverwaltung Die Check-Point-Benutzerverwaltung ordnet den Remote-Usern neben dem Benutzernamen auch Eigenschaften wie die Authentifizierungsmethode (zum Beispiel Radius, SecurID etc.) oder die Gruppenzugehörigkeit zu. Die Speicherung von Benutzern kann entweder in der Check-Point-Datenbank oder auf einem externen LDAP-Server erfolgen. Der Einfachheit halber verwalten wir die Remote-User unseres Unternehmens in der lokalen Check-Point- Datenbank. In größeren Unternehmen werden die Benutzer in der Regel auf einem LDAP-Server gepflegt. Benutzergruppen Für unsere Remote-User bietet sich die Zuordnung zu einer der beiden Benutzergruppen Mitarbeiter oder Fremdfirmenmitarbeiter an. Die Benutzergruppen werden später in der Regelbasis verwendet, um unterschiedliche Berechtigungsprofile abzubilden: Fremdfirmenmitarbeiter sollen nur auf die Ressourcen zugreifen, die sie administrieren müssen, während sich Firmenmitarbeiter im internen Netz frei bewegen, d.h. auf alle internen Ressourcen zugreifen dürfen. Um zu spezifizieren, welche Benutzer sich in den Policy Server einloggen dürfen (vgl. Abb. 6 13), definieren wir eine weitere Gruppe RemoteAccessU-

204 6 VPNs im Umfeld von Firewalls sers, die alle Remote-User, d.h. die Gruppen Mitarbeiter und Fremdfirmenmitarbeiter, enthält. Templates Im Folgenden werden wir für die beiden Benutzergruppen jeweils ein Template definieren. Ein Template kann man sich als einen allgemeinen Benutzer mit bestimmten Eigenschaften (Eigenschaften sind zum Beispiel die Authentifizierungsmethode und die Gruppenzugehörigkeit) vorstellen. Legt man später einen konkreten Benutzer an und ordnet ihm ein Template zu, erbt der Benutzer alle im Template festgelegten Eigenschaften. Für unsere Templates sind besonders die Eigenschaften Gruppenzugehörigkeit (GROUPS in Abb. 6 16), Authentifizierungsmethode (AUTHENTICA- TION) und Verschlüsselungseigenschaften (ENCRYPTION) von Interesse. Abb. 6 16 Definition eines Templates für die Mitarbeiter unseres Unternehmens Die Authentifizierungsmethode und die Verschlüsselungseigenschaften sind für beide Gruppen identisch. Die Authentifizierungsmethode ist für alle Remote-User RADIUS, da sowohl für Mitarbeiter als auch für Fremdfirmenmitarbeiter derselbe Radius-basierte Authentifizierungsserver verwendet

6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 205 wird. Die Templates unterscheiden sich lediglich in der Gruppenzugehörigkeit. Tab. 6 2 fasst die vorgenommenen Einstellungen zusammen. TL_Mitarbeiter TL_Fremdfirmenmitarbeiter Groups Mitarbeiter Fremdfirmenmitarbeiter Authentication Encryption Radius IKE. In den IKE-Eigenschaften muss unter AUTHENTICATION»Public Key«ausgewählt werden (Authentifizierung der Firewall gegenüber dem Client). Tab. 6 2 Definition der Templates für Mitarbeiter (TL_Mitarbeiter) und Fremdfirmenmitarbeiter (TL_Fremdfirmenmitarbeiter) Anlegen von Benutzern Unter Verwendung der Templates können nun sehr einfach Benutzer angelegt werden, da nur noch der Benutzername angegeben werden muss. Alle anderen Eigenschaften werden vom Template vererbt (siehe Abb. 6 17). Abb. 6 17 Anlegen von Benutzern unter Verwendung der Templates VPN Community Die Zuordnung, welche Benutzergruppen mit welchen Gateways Remote-Access- VPNs aufbauen dürfen, wird über die Remote Access Community im VPN Manager des SmartDashboard definiert. Wir nennen die VPN Community RemoteAccess und wählen unser Firewall-Gateway fw_ext (Abb. 6 18) sowie die oben definierte Benutzergruppe RemoteAccessUsers (Abb. 6 19) aus. Abb. 6 18 Auswahl des Gateways für die Remote Access Community

206 6 VPNs im Umfeld von Firewalls Abb. 6 19 Auswahl der Benutzergruppe für die Remote Access Community Regelbasis Die Regelbasis aus Abb. 4 13, Abb. 4 14 und Abb. 4 15 muss für unser Remote- Access-VPN in zweierlei Hinsicht erweitert werden. Zum einen müssen Regeln definiert werden, um die IPSec-Kommunikation und den Topologie-Download zwischen Client und Firewall zu ermöglichen (Regel 4 in Abb. 6 20), zum anderen müssen benutzerbezogene Regeln angelegt werden, die den Remote-Usern den Zugang zu internen Ressourcen ermöglichen (Regel 6 und 7 in Abb. 6 20). Bei diesen Regeln ist die Spalte VPN der Regelbasis von Bedeutung, in der unsere Remote Access Community RemoteAccess ausgewählt werden muss. Regel 4 ermöglicht beliebigen externen IP-Adressen den Download der Topologie sowie den Aufbau von IPSec-Tunneln. Weil die IP-Adressen der Clients nicht vorhergesagt werden können, müssen unter SOURCE alle denkbaren IP-Adressen zugelassen werden. Der Topologie-Download sowie der Aufbau des IPSec-Tunnels ist freilich nur für authentifizierte Benutzer möglich. Regel 6 gestattet Remote-Usern, die der Gruppe Mitarbeiter zugeordnet sind (d.h., der User wurde unter Verwendung des Templates TL_Mitarbeiter angelegt), den freien Zugang zu allen internen Ressourcen. Fremdfirmenmitarbeiter dürfen nur auf die Ressourcen zugreifen, die sie benötigen, um ihren Wartungsauftrag zu erfüllen (Regel 7). Die Hostobjekte unter DESTINATION (ERP und SAP) mussten zuvor definiert werden.

6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 207 Abb. 6 20 Erweiterte Regelbasis unserer externen Firewall. Neu sind die Regeln 4, 6 und 7.

208 6 VPNs im Umfeld von Firewalls Desktop Policy Die Regelbasis für die Personal-Firewall des SecureClients, die so genannte Desktop Policy, wird ebenfalls mit dem Check Point SmartDashboard angelegt. Für unser Unternehmensnetzwerk wollen wir mit der Desktop Policy erreichen, dass Anwender, die über IPSec mit der Firma verbunden sind, nicht gleichzeitig mit dem Rest des Internets kommunizieren dürfen. Die Regelbasis aus Abb. 6 21 erfüllt diesen Zweck. Bei der Desktop Policy wird zwischen Inbound- und Outbound-Regeln unterschieden. Mit den Regeln unter INBOUND werden Kommunikationsbeziehungen definiert, die von außen (Internet, Firmennetz) zum Remote-PC hin aufgebaut werden. Umgekehrt beschreiben die Regeln unter OUTBOUND die Kommunikationsbeziehungen zwischen dem Remote-PC und dem Rest der Welt. Die Regeln 1 und 3 in Abb. 6 21 ermöglichen die freie Kommunikation zwischen Firmennetz und Remote-PC (Regel 1) und umgekehrt (Regel 3). Die Regeln 2 und 4 verbieten jeglichen sonstigen Netzwerkverkehr. Die abgedruckte Regelbasis gilt sowohl für die Mitarbeiter des Unternehmens als auch für die Fremdfirmenmitarbeiter. Die Unterscheidung zwischen Mitarbeiter und Fremdfirmenmitarbeiter erfolgt bei uns nicht in der Desktop Policy, sondern gatewayseitig in Form von benutzerbezogenen Regeln (siehe Abb. 6 20). In unserem Fall hat die Desktop Policy lediglich den Zweck sicherzustellen, dass keine Kommunikation mit dem Internet möglich ist, während der Anwender mit der Firma kommuniziert. Abb. 6 21 Desktop Policy

6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk 209 6.3.3 Clientseitige Konfiguration Installation Bei SecuRemote und dem SecureClient handelt es sich um ein und dasselbe Installationspaket. Während der Installation ist auszuwählen, ob SecuRemote oder der SecureClient zum Einsatz kommen soll. Für die Rechner unserer Remote-User verwenden wir ausschließlich den SecureClient. Nach einem Reboot ist die Installation abgeschlossen. Konfiguration Nach der Installation muss über das GUI die so genannte Site angelegt werden (siehe Abb. 6 22). Dabei wird dem SecureClient die externe IP-Adresse des Gateways bekannt gemacht, zu dem der Tunnel hin aufgebaut werden soll. In unserem Fall ist dies die IP-Adresse 140.252.90.241. Außerdem ist die Authentifizierungsmethode auszuwählen. Diese ist in unserem Fall»Challenge Response«, da wir dynamische Einmalpasswörter verwenden. Abb. 6 22 Anlegen einer Site Im Anschluss an das Anlegen der Site startet der Topologie-Download. Hierzu muss sich der Anwender authentifizieren. Die Topologie-Informationen, unter anderem die VPN Domain, werden im Installationsverzeichnis des SecureClients im Unterordner database in der Datei userc.c gespeichert.

210 6 VPNs im Umfeld von Firewalls 6.3.4 Aufbau eines Tunnels zum Firmennetzwerk Abschließend wird anhand einer beispielhaften Sitzung der Ablauf des Tunnelaufbaus beschrieben: Ein Außendienstmitarbeiter unseres Unternehmens mit dem Namen Maier möchte abends im Hotel seine E-Mails abrufen. 1. Herr Maier wählt sich bei seinem ISP (zum Beispiel T-Online) ins Internet ein. 2. Er startet den Tunnelaufbau zur Firma, indem er auf das SecureClient- Icon doppelklickt. Der CONNECT-Button im daraufhin erscheinenden Fenster (siehe Abb. 6 23) löst den Tunnelaufbau aus. Abb. 6 23 Start des Tunnelaufbaus 3. Herr Maier wird vom SecureClient zur Eingabe seines Passworts aufgefordert. Er gibt das dynamische Einmalpasswort ein, das er von seinem Token abliest. 4. Nach erfolgreicher Authentifizierung werden die Tunnelparameter ausgehandelt, und der SecureClient loggt sich in den Policy Server ein, um die Desktop Policy herunterzuladen und anschließend zu aktivieren.

6.4 Konfiguration eines Site-to-Site-VPNs für das Firmennetzwerk 211 5. Der Tunnel zwischen dem Laptop von Herrn Maier und der Firewall fw_ext unseres Unternehmens wurde aufgebaut. Die Personal-Firewall ist aktiv. 6. Herr Maier startet seinen Mail-Client (Microsoft Outlook), der eine Verbindung zum Exchange-Server aufbaut. Der SecureClient erkennt anhand der Topologie, dass sich der Exchange-Server in der VPN Domain von fw_ext befindet, und verschickt das Paket daher über den Tunnel zur Firewall. Dort wird die offizielle Adresse des Providers in eine Adresse aus dem IP Pool NAT-Bereich 10.10.10.0/24 übersetzt. 6.4 Konfiguration eines Site-to-Site-VPNs für das Firmennetzwerk 6.4.1 Ausgangssituation Da unser Unternehmen aus der Fertigungsindustrie kürzlich Teile seiner Entwicklung an eine Partnerfirma auslagert hat, besteht die Notwendigkeit, dass die Partnerfirma Zugriff auf das Entwicklungssystem enthält. Dieses befindet sich im internen Netzwerk unseres Unternehmens und hat die IP-Adresse 10.10.100.50 (siehe Abb. 6 24). Eine Möglichkeit, um den sicheren und kontrollierten Zugriff der Partnerfirma auf dieses System zu gewährleisten, bestünde in der Nutzung des im vorherigen Abschnitt aufgebauten Remote-Access-VPNs. In diesem Fall müssten alle Mitarbeiter der Partnerfirma, die auf das Entwicklungssystem zugreifen dürfen, mit Hardware-Tokens ausgestattet werden und auf ihren Rechner den Check Point SecureClient installieren. Da Letzteres seitens der IT-Leitung der Partnerfirma nicht erwünscht ist, hat unser Unternehmen in Absprache mit der Partnerfirma beschlossen, ein Site-to-Site-VPN zwischen den externen Firewalls der beiden Unternehmen auszubauen. Hierbei handelt es sich bei der Partnerfirma um eine Cisco-PIX-Firewall; in unserem Unternehmen wird die Check Point Fire- Wall-1/VPN-1 eingesetzt. Ein weiterer Grund für den Einsatz eines Site-to-Site-VPNs anstelle eines Remote-Access-VPN ist der Umstand, dass über 100 Entwickler auf das Entwicklungssystem zugreifen sollen. Bei der Realisierung des Zugriffs über ein Remote- Access-VPNs würde dies für unser Unternehmen vergleichsweise hohe Kosten für die Bereitstellung der Hardware-Tokens bedeuten.