Für das Management von Remote-Standorten geben drei Faktoren den Ausschlag: Geld, Ressourcen (Equipment und Personal) sowie Zeit.

Nichts macht IT-Effizenzen – und Ineffizienzen – offensichtlicher als Remote-Standorte. Und trotz vollmundiger Versprechen der Hersteller gibt es keine Universallösung – Remote-Support ist komplex und an die jeweilige Infrastruktur und die Systeme gebunden. Aber es gibt akzeptierte, erprobte Praktiken für das Management von Zweigstellen und -niederlassungen. Aus zahlreichen Praxisbeispielen lassen sich lehrreiche Schlüsse ziehen. Die Namen der involvierten Unternehmen bleiben ungenannt, denn diese Details sind nicht wichtig. Der Schlüssel zum Erfolg ist immer das Konzept.

Die Philosophie: Beim Management von Remote-Standorten geht es nicht um spezielle Produkte, sondern um die Pflege von Standards und die Ausdehnung der Core-Infrastruktur, der Richtlinien und der Systeme des Unternehmens. Unternehmen, die Remote-Standorten erlauben, einmalige Technologien zu implementieren, verlieren die Kostenvorteile der Standardisierung. Obwohl Migrationen zu mehr WAN-freundlichen Technologien zu erwarten sind, ist an Unternehmensstandards festzuhalten.

Das zentralisierte IT-Gruppenmodell bildet hier den Schwerpunkt. Natürlich gibt es andere Wege, Remote-Büros zu unterstützen, aber dieser zentrale Ansatz ist der am häufigsten genutzte – in unserer Umfrage nannten ihn 64 Prozent der befragten IT-Manager.

Der erste Schritt ist die Untersuchung der existierenden Systeme und der Infrastruktur sowie die Entwicklung eines »Fahrplans«, der den Standort des Remote-Supports und die zu erwartenden Hindernisse definiert. Das klingt einfach, aber trotzdem ist dies ein häufig vernachlässigter Punkt. Falls es sich bei der Organisation nicht gerade um eine Neugründung handelt, wird eine Infrastruktur vorhanden sein, auf der die Systeme aufbauen. Gibt es dort ältere Technologie, die ein effizientes Remote-Site-Management erschwert? Lässt sie sich aussondern? Der Fahrplan sollte Zeitrahmen für die Migration von Legacy-Applikationen enthalten.

Remote-Support-Methoden und -Werkzeuge sollten ebenfalls Teil des Plans sein. Lokal ausgeführte Deployment-Werkzeuge haben vielleicht nicht die notwendige Bandbreite, wenn sie über langsamere WAN-Verbindungen laufen. Hüten muss man sich auch vor der Implementation scheinbar kosteneffizienter taktischer Lösungen für kurzfristige Probleme. Der IT-Manager muss voraussehen, wann neue Projekte Vertragserneuerungen, ein Wachstum der Kommunikationsleitungen und Technologieänderungen erfordern. Auf diese Weise vermeidet er teure Neuentwicklungen und Bugetkämpfe.

Plant man nicht gleich am Anfang alle Details eines Projekts, wird man wieder und wieder von vorn beginnen müssen. Ein Beispiel dazu: Ein schnell wachsendes Unternehmen führte in einem LAN Applikationen aus, die ganz vernünftig funktionierten – bis Remote-Standorte Zugriff verlangten. Die Bandbreite, die für die Remote-Ausführung einer Schlüsselapplikation notwendig war, sprengte das Budget. Zum Glück für dieses Unternehmen ließ sich diese Applikation in einer Unix-Umgebung mit echter Client-Server-Datenbank ausführen, was die Kommunikation auf Bildschirmaktualisierungen und Tastatureingaben reduzierte. Die Lösung in diesem Fall war also die Migration auf eine andere Server-Plattform, aber es hätte schlimmer kommen können. Man stelle sich vor, der Entwickler der Applikation hätte keine Client-Server-Version des Programms angeboten oder die Datenbank wäre nicht cross-platform-fähig gewesen. Solche Probleme lassen sich schon zum Zeitpunkt der Systemauswahl vermeiden, indem man ganz einfach darauf achtet, dass die Applikation für künftige Zweigstellen-Ausweitungen geeignet ist. Hätte das erwähnte Unternehmen gleich die Unix-Version implementiert, hätte es sich die Kosten der Datenmigration, der Plattformumstellung und der Re-Implementierung gespart.

Bei der Systemauswahl bietet es sich an, funktionsübergreifende Teams einzusetzen, um solche Probleme, wie sie das folgende Beispiel beschreibt, gar nicht erst auftauchen zu lassen: Ein produzierendes Unternehmen kaufte ein auf LAN basierendes Verkaufs-Management-Programm, das eine Update-Funktion für die Datensynchronisation enthielt. Als das Programm einem Standort über das WAN zur Verfügung gestellt wurde, brachten Verzögerungen durch langsamere Verbindungen und gelegentliche Netzwerk-Congestion es zum Absturz.

In diesem Fall hatte der Software-Hersteller vergessen, Fehlerbehandlungsroutinen zu implementieren, die WAN-Funktionalität unterstützen – trotzdem warb der Hersteller mit der Fähigkeit des Produktes, eine Synchronisation von überall zu unterstützen. Es gab keine Fehlerroutinen, die sich um die Toleranz für langsamere WAN-Verbindungen auf der Anwendungsschicht kümmerten, obwohl die Synchronisationsaktivitäten auf dieser Schicht gesteuert wurden. Während der Software-Hersteller an diesem Problem arbeitete, war die kurzfristige Lösung ein Aufblasen der WAN-Geschwindigkeiten, um die Sync-Funktion näher an die Remote-Standorte zu rücken. Diese Situation hätte vermieden werden können, wenn die Applikationsgruppe während des Software-Evaluierungsprozesses auch Mitglieder des Netzwerk-Teams enthalten hätte. Stattdessen machte die Applikationsgruppe lediglich eine Annahme, basierend auf den Aussagen des Herstellers, ohne das Produkt einem Akzeptanztest durch die Netzwerkgruppe unterziehen zu lassen.

Die goldene Triade

Die meisten IT-Mitarbeiter wurden schon einmal gefragt: »Können wir das machen?« Unabhängig davon, ob es um Zweigstellen-Support geht oder darum, einen Verkäufer auf den Mond zu schicken, lautet die Antwort üblicherweise: »Aber selbstverständlich – vorausgesetzt, wir haben unbegrenzte Zeit, unlimitiertes Geld, Equipment und Personal.« Da unlimitierte Ressourcen ein Ding der Vergangenheit sind, sollte man auf diese Frage mit folgenden drei Fragen antworten:

• Geld: Wie viel können wir ausgeben?

• Ressourcen: Was steht an Equipment und Personal zur Verfügung?

• Zeit: Wie viel Zeit haben wir, bis wir liefern müssen?

Erfahrungsgemäß müssen diese drei Dinge stets ausgewogen sein. Wie bezieht sich dies nun auf Remote-Standorte? Hier ist ein Beispiel: Bei der Kalkulation der Kosten für den Support des Remote-Standorts berücksichtigt der IT-Manager die offensichtlich erweiterten Infrastrukturausgaben, führt aber auch eine Risikoanalyse durch, die Untersuchungen der Fehlerpunkte enthält und einschätzt, wie Downtime das Geschäft beeinträchtigt. Vielleicht wird er nach der Ausarbeitung eines auf den Geschäftskosten der Downtime basierenden Service-Level-Agreements feststellen, dass das Budget nicht ausreicht, um dieses Projekt zu unterstützen.

Geld sparen zu wollen ist sicher lobenswert, aber dabei ist vorsichtig vorzugehen, denn die Dinge sind nicht immer so preiswert, wie sie erscheinen: Ein Unternehmen entschloss sich, für alle Remote-Zweigstellen VPNs über das Internet zu implementieren. Die Antriebskraft dafür waren WAN-Kosteneinsparungen. Auf dem Papier sah das gut aus, bis das erste ISP-Netzwerk ausfiel. Ohne Backup-Netzwerk schwamm das Unternehmen tot im Wasser. Das Management machte die IT-Abteilung dafür verantwortlich, die vergessen hatte, die Wahrscheinlichkeit und die Kosten einer Downtime einzuschätzen und Wege vorzuschlagen, dieses Risiko abzuschwächen. Hätte man diese Informationen gleich zu Anfang gehabt, wäre einigen Leuten eine Menge Ärger erspart geblieben.

Die Menschen sind immer die teuerste Komponente jeder IT-Bemühung. Zu entscheiden, wer an welcher Stelle einzusetzen ist, ist nicht leicht – 76 Prozent unserer Umfragebeantworter sagten, dass die Verfügbarkeit lokalen technischen Supports die größte Herausforderung darstelle. Bei der Bestimmung personeller Anforderungen für Remote-Standorte sollte Folgendes Berücksichtigung finden:

• Geographischer Standort und Zeitzone: Kann eine zentrale Support-Gruppe die Distanz und Tageszeitunterschiede unterstützen?

• Sprachschwierigkeiten: Selbst wenn Personal vorhanden ist, um von einem zentralen Standort aus 24 Stunden Support zu bieten, könnte es Sprachbarrieren geben.

• Geschäftsanforderungen: Wie lassen sich spezifische Geschäftsanforderungen am Besten erfüllen? Falls beispielsweise in einem entfernten Lager Etiketten für Paketlieferungen gedruckt werden, braucht dieses Lager direkt am Standort zuverlässigen Support für die Etikettendrucker.

• Standardisierung: Sind Unternehmens- und Industriestandards definiert, und werden sie eingehalten? Den Support fein abzustimmen bedeutet, Variablen zu reduzieren. Sind Multiprotokollumgebungen wirklich notwendig?

• Architektur: Das zur Unterstützung komplexer Architekturen notwendige Know-how verlangt vielleicht nach zusätzlichem Support – man sollte also vereinfachen, wo immer dies möglich ist. Plant der IT-Manager Redundanz für kritische Komponenten seiner Architektur? Definiert man Applikationen und unterstützt sie mit der notwendigen Architektur, oder ist es besser, Applikationen auszuwählen, die sich nahtlos in Ihre existierende Umgebung integrieren?

• Konvergenz: Ist die Datengruppe von der Sprachgruppe getrennt? Nutzen beide unterschiedliche Einrichtungen? Befindet sich die Organisation in einer guten Ausgangsposition für VoIP, einem potenziellen Kostenreduzierer? Die Unternehmenskultur und politische Spielchen können einem effizienten Remote-Site-Support Steine in den Weg legen.

Da gab es ein Unternehmen, in dem die Daten von der IT-Gruppe und die Telefone von der Liegenschaftsgruppe betreut wurden. Jede Gruppe installierte und verwaltete separate Kommunikationsleitungen. Einige Remote-Standorte verwalteten gar ihre eigenen Leitungen lokal. Durch Zusammenlegung dieser Verbindungen und Aushandlung eines neuen, einzigen großen Vertrags gelang es diesem Unternehmen, im ersten Jahr mehr als 1,5 Millionen Dollar an Kommunikationskosten zu sparen – ohne die Technologie geändert zu haben.

Mit kreativen Lösungen lassen sich möglicherweise Technologiehürden und politische Lager überspannen, wie folgendes Beispiel demonstriert: Ein Unternehmen benötigte X.25-Kommunikation, um Remote-Standorte anzubinden. Die Netzwerkgruppe bestand aus zwei Fraktionen: Die eine favorisierte progressivere auf IP basierende Systeme, die andere bestand auf getestete X.25-Systeme. Argumente wurden vorgebracht. Die kreative und einfache Lösung war, dort, wo zuverlässiger Transport und vereinfachte Transition zu auf IP basierenden Systemen erforderlich war, IP durch das X.25-Netzwerk zu tunneln.

Der große Hammer: Kommunikationskosten

Beim Anbinden von Remote-Standorten sind die Kommunikationsdienste Hauptkomponenten – und Hauptkosten. Ohne diese Dienste gäbe es keine Kommunikation, keinen Systemzugriff und keine Echtzeitoperationen. Hier Eventualitäten einzuplanen, ist also wichtig.

Viele Newcomer im Networking-Beruf sagen, dass ein VPN alles sei, was man zum Anbinden von Remote-Standorten benötigt. Ein VPN mag zwar kosteneffizient aussehen, aber ohne gründliche Geschäftsanalyse und Service-Level-Agreement operiert man am Rand der Galaxis. Verantwortlichkeit und Verantwortung gehen Hand in Hand – das Geschäft des Unternehmens (und der Job des IT-Managers) sollten nicht abhängig sein von einem Netzwerk, für das niemand direkt verantwortlich ist. Welchen Service-Level kann man schon für auf Internet basierende Systeme garantieren?

Es führt kein Weg daran vorbei: IT-Manager, die Remote-Standorte unterstützen, müssen ihre Hausaufgaben zum Thema WAN-Connectivity erledigen. Dazu gehört, sich die potenziellen Auswirkungen von Designentscheidungen anzusehen und den Verkehr zu analysieren, um den aktuellen Netzwerk-Verkehrsfluss und potenzielle Flaschenhälse zu identifizieren. Migrationspfade zu neuen Technologien und VoIP-Konvergenz sind zu untersuchen und in die Gleichung einzubringen. Die Verkehrsanalyse gibt dem IT-Manager außerdem die Gelegenheit, den Gürtel enger zu schnallen und sicherzustellen, dass kein unnötiger Verkehr das WAN passiert.

Es gilt also, sich zuerst zu informieren und dann erst zu starten. Auch dazu ein kurzes Beispiel aus der Praxis: Einem Unternehmen wurde das einzelne Bürogebäude zu klein. Das Management entschied, die Engineering-/Entwicklungsgruppe in einen neuen Standort ein paar Kilometer entfernt zu verlegen. Standleitungen wurden in Auftrag gegeben, deren Bandbreite der IT-Manager aus dem Bauch heraus bestimmte, statt Nutzungsstatistiken heranzuziehen. Tag eins war ein Albtraum: Die zugeordnete Bandbreite war völlig inadäquat, und die Engineering-Teams waren stinksauer. Das Geschäft kam zum Erliegen. Der IT-Manager hätte dem Netzwerkteam erlauben sollen, den Netzwerkverkehr der betroffenen Gruppen zu überwachen, um die erforderliche Bandbreite genau zu bestimmen. Verblüffend war, dass der IT-Manager einfach nur sagte, »na, da müssen wir wohl ein paar Bugs entfernen«. Man hätte dies sicher auch als eine die Karriere beendende Entscheidung betrachten können.

Fehler lassen sich auch vermeiden, wenn man sich ein wenig Zeit nimmt und nicht zu hastig vorgeht: Ein Unternehmen war in so großer Eile, seine Systemumstellung zum Abschluss zu bringen, dass es ISDN-Wählverbinungen wählte, statt auf Standleitungen zu warten. Die Router wurden so konfiguriert, dass sie Verbindungen so herstellten, wie sie angefordert wurden. Nach der Implementation »vergaß« die zentrale Netzwerkabteilung, die ausgehenden Verbindungen zu beobachten, und einiger Keep-alive-Verkehr sorgte dafür, dass alle fünf Minuten unnötige Verbindungen hergestellt wurden. Als die Rechnung eintraf, übertraf sie alle Vorstellungen. In der Eile, die Dinge erledigt zu bekommen, wurden teure Router-Konfigurationsfehler gemacht. Noch schlimmer war aber, dass diese Fehler nicht bemerkt wurden, bis in der Buchhaltung die roten Lampen angingen.

Bei der Kapazitätsplanung für neue Kommunikationsleitungen oder Kapazitätserweiterungen sollte man keinesfalls Backup-Einrichtungen vergessen: Eine bundesweit tätiges Unternehmen mit zentraler Operationsbasis besaß mehrfache Kommunikationsleitungen für Sprache. Eine Leitung diente als Backup für Sprach- und Datenkommunikation. Das Equipment war dafür programmiert, den Verkehr automatisch zum Backup zu routen, sollte es zu einem Fehler im Hauptkreis kommen. Eines Tages war es soweit: Eine Hauptleitung fiel aus. Das Equipment leitete den Verkehr prompt zum Backup-Kreis – der allerdings ebenfalls tot war. Die Kreise terminierten am selben Endpunkt, so dass die einzige wirkliche Redundanz nur lokal war.

Die große Belastung: Manpower

Je weniger das Management von Remote-Standorten anfänglich geplant wird, desto häufiger muss der IT-Stab später eingreifen. Einige Unternehmen betrachten Remote-Control-Software als Allheilmittel für das Management von Remote-Standorten mit wenig Personal. Aber das ist kein Ersatz für eine sorgfältige Planung.

Sind die Endbenutzer gut geschult? Sind effiziente Patch-Management-Systeme einsatzbereit? Dürfen Benutzer ihre eigene PC-Konfiguration verändern? Alle diese Faktoren beeinflussen, wie sehr diese Benutzer vom Support-Personal abhängig sind.

Was ist also der beste Weg, Remote-Standorte physisch zu verwalten? Es reduziert sich einmal mehr auf Zeit, Geld und Ressourcen. Die meisten Organisationen setzen auf einen zentralen IT-Stab, der weniger kostet und weniger Ressourcen beansprucht. Aber diese Gruppe kann gebunden werden durch unnötige und Zeit raubende Troubleshooting-Tätigkeiten, die sich durch besseres Training, standardisierte Systeme und Controls vermeiden ließen. Hier sind einige Varianten zum Modell des zentralen IT-Stabs:

• Outsourcing: Dies ist zwar die teuerste Option, aber den IT-Support außer Haus zu geben, könnte gut passen für einige Standorte, die nur schwer erreichbar sind oder die 24/7-Support erfordern. Bei kleinem IT-Stab ist dies ebenfalls eine gute Lösung. Tatsächlich sagten 31 Prozent unserer Umfragenbeantworter, dass sie Technologie-Support von außerhalb nutzen. Die Anbieter sind zu fragen nach der Ausdehnung ihrer Support-Aktivitäten, ihrer geographischen Reichweite und Abdeckung, der Qualität und Konsistenz des Dienstes, der Reaktionszeit und Mantelverträgen für sämtliche Standorte. Man beachte, dass einige Anbieter zwar an mehreren Standorten präsent sind, deren Büros aber unabhängig voneinander arbeiten, weshalb die Reichweiten, die Dienstqualitäten und Reaktionszeiten unterschiedlich sein können.

• Abteilungs-Liaisons: Sind Abteilungs-Manager dazu bereit, für schnelle Reaktionen Personal zur Verfügung zu stellen, könnte dies eine zuverlässige Option sein. Technisch versierte Endbenutzer erhalten ein gründliches Training durch die IT-Gruppe und dienen anschließend als zentraler Kontaktpunkt und erste Linie für Basis-Troubleshooting-Aufgaben in ihren Abteilungen.
• IT im Standort: Je nach Architektur und Größe des Remote-Büros ist dies die zuverlässigste Option. Sie ist zwar teuer, aber in vielen Fällen immer noch günstiger als Outsourcing. Die Herausforderung ist, geeignetes Personal zu finden und langfristig zu behalten. Die Kandidaten müssen Disziplin besitzen, über Fachwissen verfügen und hoch motiviert sein. Mehr als 43 Prozent der Beantworter unserer Umfrage gaben an, dass sie IT-Support-Personal in den Zweigstellen haben.

Eins der überraschendsten Ergebnisse unserer Umfrage ist, dass mehr als 34 Prozent der Beantworter keinen Support oder nur Ad-hoc-Support durch IT-fremdes Personal in den Zweigstellen haben. Dieses Versäumnis kann zu Sicherheitsproblemen und ineffizienter Systemnutzung führen, weil IT-fremdes Personal ungehörig viel Zeit mit dem Lösen von Problemen verbringt, die nichts mit dem eigentlichen Job zu tun haben.

Die Stütze des Supports: Standards

Dies ist zwar keine direkte Kostenüberlegung, aber die Effizienz die sich beim Remote-Deployment und -Support erreichen – oder nicht erreichen – lässt, hängt ab von der Standardisierung im Unternehmen. Nahezu 45 Prozent der Umfragebeantworter nannten die Einhaltung von Standards als größte Herausforderung für Remote-Zweigstellen. Sind Standards eingesetzt, kann das Unternehmen Hersteller wechseln, ohne sich über Wissenstransfer sorgen zu müssen, und der Support-Stab ist austauschbar.

Falls PC-Hardware standardisiert ist, können Hot-Spares vom Support-Personal gepflegt und eingesetzt werden, um die Downtime zu reduzieren. Der Vorrat lässt sich im Remote-Standort oder zentral lagern. Standardisierung auf eine limitierte Anzahl von Software-Konfigurationen bedeutet, dass Imaging-Software zur schnellen Wiederherstellung einer funktionierenden Konfiguration effizient einsetzbar ist. Ein Rollback lässt sich selbst in der Nacht remote aufsetzen, um Versandkosten und potenzielle Beschädigungen des Equipments zu reduzieren.

Falls einige Komponenten sich nur schwer oder langsam beschaffen beziehungsweise installieren lassen, sollte in den Remote-Standorten Ersatz dafür vorhanden sein. Eine gute Idee ist auch ein »IT-Erste-Hilfe-Set« mit den üblichsten Ersatzteilen, beispielsweise Netzteile, denn manchmal sind die Teile eben nicht am nächsten Tag da: Ein bundesweit tätiges Unternehmen verfolgte die Praxis »Versand über Nacht«, um Hot-spare-PCs als Ersatz für fehlerhafte Remote-Maschinen auf den Weg zu bringen. In einem Fall mussten drei verschiedene Lieferungen getätigt werden, bevor der interne Kunde einen funktionierenden Ersatz hatte. Trotz sorgfältiger Verpackung durch das IT-Team trafen die PCs beschädigt ein – ein PC wurde gar so »schonend« behandelt, dass sich sämtliche interne Karten vom Motherboard gelöst hatten. Es dauerte vier Tage, bis der Benutzer wieder online war. Überlegenswert ist es also, Ersatz direkt am Remote-Standort bereitzuhalten, falls es die Sicherheit und Kosten erlauben.

Der Teufel in der Dokumentation

In unserer Umfrage baten wir, Werkzeuge des Remote-Site-Management in der Reihenfolge ihrer Wichtigkeit zu nennen. Die Dokumentation wurde an zwölfter und damit letzter Stelle genannt. Das ist nicht gut, denn es ist so leicht und preiswert, eine gute Dokumentation zu produzieren, besonders im Vergleich mit den Schwierigkeiten und Kosten, einen Remote-Standort kennen zu lernen. Personal des zentralen Büros hat vielleicht noch nie einen Fuß in den Remote-Standort gesetzt, den es unterstützt. Detaillierte Informationen über den Standort, darunter Referenzmaterial, Gebäudepläne, Diagramme, Fotos, Verkabelungsdetails und Equipmentlisten sind unschätzbar wertvoll. Produkte wie Netviz helfen, diese Informationen zusammenzustellen und zu organisieren, aber ein wenig Mühe ist schon notwendig.

Neben dem Erzeugen von Richtlinien und dem Anfertigen einer Dokumentation ist die Informationsverbreitung die wichtigste Komponente. Die Remote-Standorte müssen das Vorhaben unterstützen, sonst ist die Schlacht verloren. Um diese Unterstützung zu gewinnen, muss den Zweigstellen die gleiche Aufmerksamkeit geschenkt werden wie den lokalen Abteilungen.

Datenspeicher und Backup

Unabhängig von den Applikations- und Technologieplattformen sind das Unternehmenswissen und Personalinvestitionen durch solide Backup-Operationen zu schützen. Dies lässt sich auf mehreren Wegen erreichen, beispielsweise durch zentrale oder dezentrale Server. Um festzustellen, was individuell für ein Unternehmen am Besten funktioniert, sind drei Fragen zu beantworten:

• Wo? Werden Daten über Kommunikationsleitungen per Push oder Pull übertragen? Stehen automatische Libraries zur Verfügung, oder führt der Stab Backups manuell durch?

• Wann? Ist das Downtime-Fenster groß genug, um den gewählten Ansatz zu unterstützen? Die Zeit diktiert vielleicht die Technologieanforderungen und Backup-Strategien.

• Wie? Sind Echtzeit-Backups durchführbar? Müssen die Daten für das Backup offline gesammelt werden? Datengröße und Arbeitszeit werden beeinflussen, wie Datenreplikationsstrategien und Zeitrahmen angegangen werden können.

Die einzigen Kosten, die höher sind, als die Kosten der Kommunikationskomponenten, sind die Personalkosten. Das Personal und der Support für Remote-Datenspeicher und Server sind mit Applikations- und Infrastrukturkosten aufzuwiegen. In einigen Fällen werden archaische LAN-Applikationen mehr Remote-Server erfordern, um die Kommunikationskosten gering und die Antwortzeiten gesund zu halten.

Sicher bleiben

Und schließlich die Sicherheit. Remote-Standorte sind Erweiterungen der Unternehmensinfrastruktur, und sie sind genau zu beobachten. Wie wird beispielsweise die Sprach-/Datenkommunikation des Remote-Standorts mit der Außenwelt geregelt? Eine Option ist, sie durch das zentrale Büro zu routen und einen einzelnen Zugriffspunkt beziehungsweise eine einzelne Firewall zu nutzen. Aber dies belastet die WAN-Bandbreite zusätzlich. Eine andere Option ist, Zugriffspunkte/Firewalls in den Remote-Zweigstellen zu installieren. Durch vorsichtige Analyse des Verkehrs und Einschätzen von Remote-Support, Sicherheit und Kostenüberlegungen wird der IT-Manager zur richtigen Entscheidung für sein Unternehmen gelangen.

Besondere Beachtung verdienen die Home-Benutzer. Häufig via VPN verbunden, sind deren Remote-PCs ein integraler Bestandteil der Infrastruktur. Grundsätzliche Sicherheitsrichtlinien müssen eingerichtet sein, bevor diese Art von Verbindung genutzt wird.

Die Verteidigung muss beweglich und schnell sein. Neben Sicherheits-Patch-Werkzeugen sind solche für das Konfigurations-Management erforderlich, damit sich potenzielle Löcher schnell schließen lassen. Außerdem Intrusion-Detection-Werkzeuge, die über anormale Aktivitäten in den Remote-Standorten informieren. [ nwc, dj ]