BEKOM CLOUDSichere StandortanbindungVPN, SD-WAN und Zero Trust
BEKOM Cloud für sichere Standortanbindung: VPN- und SD-WAN-Grundmodelle, Netzwerksegmentierung und Zero-Trust-Zugriff für Multi-Site-Betrieb mit dediziertem Unternehmensnetz.
Grundmodelle der Standortanbindung
Wenn Unternehmen mit Standorten im Euroraum ihre Systeme in BEKOM Cloud integrieren, steht am Anfang die Frage nach der Netzwerkanbindung: Wie werden Hauptsitz, Produktionsstandorte und Außenstellen mit dem zentralen Cloud-Kern in Deutschland verbunden? Die Antwort hängt von Standorttyp, Nutzerzahl, Anwendungsprofil und lokalen Gegebenheiten ab. BEKOM Cloud unterscheidet drei Grundmodelle, die sich in Aufbau, Betriebsaufwand und Eignung für unterschiedliche Standortprofile klar voneinander trennen lassen.
Sichere Standortanbindung ist Betriebsvoraussetzung für geschäftskritische Anwendungen wie ERP-Systeme, die standortübergreifend auf zentrale Cloud-Ressourcen zugreifen müssen. Die Verfügbarkeit der Netzwerkverbindungen bestimmt direkt die Funktionsfähigkeit der operativen Geschäftsprozesse in Produktion, Vertrieb und Verwaltung.
Site-to-Site VPN über das Internet
Das klassische Modell verbindet Standorte über verschlüsselte Tunnel, die auf Basis der vorhandenen Internetanschlüsse aufgebaut werden. BEKOM richtet an jedem Standort einen VPN-Endpunkt ein und betreibt eine permanente Verbindung zum zentralen Cloud-Kern.
Merkmale:
- Nutzt den vorhandenen Internetanschluss ohne zusätzliche Leitung
- Geeignet für Standorte mit moderatem Datenaufkommen und Standard-Anwendungsprofil
- Performance abhängig von Qualität und Auslastung des Internetanschlusses
- Reproduzierbare Konfiguration über alle Standorte nach einheitlicher Vorlage
SD-WAN für priorisierten Verkehr
Bei SD-WAN werden mehrere Internetverbindungen pro Standort gebündelt und Anwendungsklassen unterschiedlich priorisiert. Geschäftskritische Anwendungen wie Videokonferenzen oder ERP-Zugriffe erhalten Vorrang vor unkritischem Datenverkehr.
Merkmale:
- Anwendungsspezifische Priorisierung über mehrere Leitungen hinweg
- Automatisches Umschalten zwischen Leitungen bei Ausfällen
- Zentrale Steuerung der Verkehrsregeln für alle Standorte
- Geeignet für größere Standorte und Produktionsbetriebe mit hohen Verfügbarkeitsanforderungen
Private-Line-Anbindung als Ergänzung
Für Standorte mit sehr hohen Bandbreiten- oder Verfügbarkeitsanforderungen kann eine dedizierte Leitung als Ergänzung eingesetzt werden. Sie ergänzt VPN oder SD-WAN, ersetzt sie aber nicht als Standardmodell.
Merkmale:
- Feste Bandbreite ohne Konkurrenz mit anderem Internetverkehr
- Ausschließlich für Standorte mit begründetem Bedarf – nicht als Standardmodell
- Höhere Kosten und längere Bereitstellungszeiten im Vergleich zu VPN und SD-WAN
- Einsatz bei Produktionsstandorten mit Echtzeitsteuerung oder strengen Latenzvorgaben
Die Zuordnung des Modells pro Standort erfolgt im Standort-Assessment auf Basis der Klassifikation aus dem Multi-Site-Management.
Netzwerksegmentierung und Security-Zonen
Standortanbindung ohne Segmentierung erzeugt ein flaches Netz: Jeder Standort ist mit jedem anderen und mit dem Cloud-Kern direkt verbunden. Das vereinfacht den Aufbau, erhöht aber die Angriffsfläche – ein kompromittierter Arbeitsplatz in einer Außenstelle hätte potenziellen Zugriff auf zentrale Systeme. BEKOM Cloud arbeitet daher mit einer segmentierten Netzwerkarchitektur, die nach Security-Zonen strukturiert ist und den erlaubten Verkehr zwischen diesen Zonen eng definiert.
Zonenkonzept und lokale Verkehrsregeln
Jeder Standort wird in logische Zonen unterteilt: Arbeitsplatz-Zone für Endgeräte, Server-Zone für lokale Server, Management-Zone für Netzwerkgeräte und Monitoring sowie eine Gast-Zone für externe WLAN-Nutzer. Zwischen diesen Zonen gelten definierte Regeln.
Regelwerk:
Verkehr zwischen Zonen wird ausschließlich über explizit erlaubte Dienste geführt
Gast-WLAN hat keine direkte Verbindung zu internen Systemen
Lokale Administratoren können die Zonenregeln nicht eigenmächtig ändern
Alle Regeln werden zentral versioniert und dokumentiert
Ost-West-Segmentierung im Cloud-Kern
Auch im zentralen Cloud-Kern wird der Verkehr zwischen Anwendungen segmentiert. ERP-Systeme, Dateidienste und Datenbanken liegen nicht im selben Netzsegment – jede Anwendungsgruppe hat eine eigene Sicherheitszone mit eigenen Zugriffsregeln.
Regelwerk:
Anwendungen kommunizieren untereinander nur über explizit erlaubte Schnittstellen
Zugriffsregeln werden zentral definiert und bei Änderungen versioniert dokumentiert
Angriffe auf einzelne Anwendungen oder Standorte werden auf ihren Ursprungsbereich begrenzt
Der Blast-Radius eines kompromittierten Systems wird durch die Segmentierung reduziert
Standortübergreifende Sicherheitsrichtlinien
Die Security-Policies gelten für alle Standorte einheitlich. Lokale Ausnahmen sind dokumentiert, zeitlich begrenzt und im Change-Prozess freigegeben – sie sind nicht der Normalfall, sondern ein kontrolliertes Abweichen von der Regel.
Regelwerk:
Firewall-Regeln, Zugriffskontrollen und Monitoring-Schwellenwerte werden zentral versioniert
Alle Standorte erhalten dasselbe Regelwerk als Basis-Konfiguration
Standortspezifische Ausnahmen haben ein Ablaufdatum und werden regelmäßig geprüft
Änderungen werden im Change-Management dokumentiert und nachvollziehbar ausgerollt
Identity-first Access und Zero Trust
Netzwerksegmentierung schützt den Datenverkehr, aber sie entscheidet nicht über Berechtigungen. Wer auf welche Anwendung zugreifen darf, regelt Identity-first Access: Die Identität eines Nutzers, das Gerät, von dem er arbeitet, und der Kontext des Zugriffs bestimmen, was er tun kann. BEKOM Cloud folgt dem Zero-Trust-Prinzip – kein Zugriff wird pauschal vertraut, jeder wird einzeln validiert, unabhängig vom Arbeitsort des Nutzers.
Single Sign-On mit Multifaktor-Authentifizierung
Die zentrale Identitätsverwaltung stellt einen einheitlichen Anmeldeprozess für alle Anwendungen bereit. Nutzer melden sich einmal an und erhalten Zugriff auf die für sie freigegebenen Systeme, ohne separate Passwörter pro Anwendung.
Umsetzung:
Multifaktor-Authentifizierung ist für privilegierte Zugriffe verpflichtend
Nutzer- und Rollenverwaltung wird zentral gepflegt
Änderungen wie neue Mitarbeiter, Austritte oder Rollenwechsel wirken auf alle Systeme
Passwörter folgen zentralen Richtlinien mit definierter Rotationslogik
Kontextbasierte Zugriffsrichtlinien
Neben Identität und Passwort werden weitere Faktoren geprüft: Kommt die Anfrage von einem verwalteten Gerät? Entspricht der Standort dem erwarteten Kontext? Ist die Uhrzeit plausibel? Solche Kontextregeln werden zentral definiert und pro Anwendung differenziert.
Umsetzung:
Zugriffsrichtlinien werden nach Anwendungsklasse gestuft und in der zentralen Governance gepflegt
Sensitive Systeme erhalten strengere Kontextregeln als allgemeine Office-Anwendungen
Zugriff von nicht verwalteten Geräten wird für sensitive Anwendungen unterbunden
Ausnahmen werden dokumentiert, im Change-Prozess freigegeben und mit Ablaufdatum versehen
Kontinuierliche Überprüfung statt einmaliger Freigabe
Zero Trust bedeutet, dass eine einmal erfolgte Anmeldung nicht dauerhaft gültig ist. Sitzungen werden regelmäßig neu geprüft, verdächtige Aktivitäten führen zur Reauthentifizierung. Bei einem Gerätewechsel oder auffälligem Verhalten wird die Sitzung beendet und erneut validiert.
Umsetzung:
Sitzungslogik und Reauthentifizierungsregeln werden zentral definiert
Auffälliges Verhalten löst eine erneute Prüfung der Sitzung aus
Gerätewechsel während einer Sitzung beenden diese automatisch
Alle Sitzungs-Ereignisse werden protokolliert und für Audits aufbewahrt
Für die detaillierte Rollenausgestaltung im Mehrländerbetrieb siehe Identity & Access im Mehrländerbetrieb.
Dedizierte Unternehmensnetzwerke
Ein zentrales Unterscheidungsmerkmal von BEKOM Cloud ist das dedizierte Unternehmensnetzwerk: Jeder Kunde erhält eine eigene Netzwerktopologie im Cloud-Kern, getrennt von anderen Kunden. Die Alternative – ein geteiltes Netz mit logischer Mandantentrennung – ist bei vielen Public-Cloud-Anbietern der Standard, bei BEKOM Cloud jedoch nicht der gewählte Ansatz.
Trennung auf Netzwerk- und Infrastrukturebene
Dedizierte Netze bedeuten, dass der Verkehr zwischen Standorten und Cloud-Kern über eigene Netzwerksegmente und eigene Übergabepunkte läuft. Es gibt keine Vermischung mit dem Verkehr anderer Kunden an gemeinsamen Knoten.
Umsetzung:
Jedes Kundennetz erhält eine eigene Netzwerktopologie mit definierten Übergabepunkten
Routing, Firewall-Regeln und Monitoring-Konfiguration sind pro Unternehmen eigenständig
Konfigurationsänderungen betreffen ausschließlich das jeweilige Unternehmensnetz
Kapazitätserweiterungen erfolgen ohne Abstimmung mit Nachbar-Mandanten
Konsequenzen für Betrieb und Nachweisführung
Die strukturelle Trennung vereinfacht die Nachweisführung. Netzwerkprotokolle, Verkehrsaufzeichnungen und Audit-Logs gehören eindeutig einem Kunden. Wer in einem geteilten Netz Auskunft über Datenflüsse geben muss, steht vor einer Abgrenzungsaufgabe – in einem dedizierten Netz entfällt diese.
Umsetzung:
Audit-Berichte und Monitoring-Daten werden pro Unternehmen getrennt geführt
Datenschutzauskünfte benötigen keine Mandantenabgrenzung
Forensische Analysen bei Sicherheitsvorfällen arbeiten auf kundenspezifischen Protokollen
Dokumentation für Zertifizierungen bezieht sich eindeutig auf die eigene Infrastruktur
Abgrenzung zu virtueller Mandantentrennung
Virtuelle Mandantentrennung arbeitet mit logischen Trennebenen innerhalb gemeinsam genutzter Infrastruktur. Für viele Anwendungsfälle reicht das aus, stellt aber zusätzliche Anforderungen an Konfigurations- und Audit-Disziplin.
Merkmale:
Dedizierte Netze verlagern den Aufwand von laufender Konfigurationsprüfung zu struktureller Trennung
Die Sicherheitslogik ist Teil der Netzarchitektur und nicht erst der Konfiguration
Betriebsmodelle mit hohem Audit-Druck profitieren besonders von der strukturellen Trennung
Mandantengrenzen bleiben auch bei Konfigurationsfehlern erhalten
Typische Fehler bei der Standortanbindung
Auch bei strukturiertem Vorgehen entstehen in Multi-Site-Projekten wiederkehrende Fehlerbilder. BEKOM dokumentiert diese als Teil jedes Standort-Assessments, damit sie im konkreten Rollout bereits im Entwurfsstand vermieden werden. Drei Muster treten besonders häufig auf und erklären die meisten späteren Nacharbeiten – sie entstehen selten aus Nachlässigkeit, sondern aus nachvollziehbaren Abkürzungen im Alltagsdruck.
Flaches Netz ohne Segmentierung
Ein häufiger Fehler beim ersten Rollout ist der Wunsch nach schneller Anbindung ohne Segmentierung. Alle Standorte werden in ein gemeinsames Netz verbunden, weil das die Konfiguration vereinfacht und die ersten Verbindungen rasch funktionieren. Die Entscheidung wirkt in der Anfangsphase pragmatisch, wird aber zur Hypothek, sobald die Umgebung wächst oder ein Audit konkrete Zonen einfordert. Die Folgen zeigen sich erst später: bei einem Sicherheitsvorfall, einer Zertifizierungsprüfung oder der Anbindung eines weiteren Standorts mit besonderen Anforderungen. Eine nachträgliche Segmentierung einer bereits produktiven Umgebung ist anspruchsvoll, weil jeder Standort während der Umstellung betroffen ist.
Folgen:
Nachträgliche Segmentierung erfordert eine Rekonfiguration aller Standorte und abgestimmte Änderungsfenster
Der Aufwand ist deutlich höher als die initiale Strukturierung, weil laufende Anwendungen berücksichtigt werden müssen
Audit-Fragen zu Zonen, Verkehrsregeln und Vertrauensgrenzen lassen sich ohne dokumentierte Segmentierung nicht belastbar beantworten
Sicherheitsvorfälle breiten sich im flachen Netz weiter aus, weil keine strukturellen Barrieren zwischen Standorten bestehen
Standortübergreifende Zugriffe lassen sich nur über zusätzliche Kontrollschichten nachträglich einhegen
Neue Zertifizierungen verlangen Nachweise, die ohne strukturelle Zonen nur aufwendig rekonstruiert werden können
BEKOM Cloud startet deshalb auch bei kleinen Umgebungen mit einer minimalen Zonenstruktur, die später ohne Bruch mitwächst.
Lokale Sonderregeln ohne Dokumentation
Ein zweites Muster ist das Ansammeln lokaler Ausnahmen. Ein Standort braucht eine spezielle Firewall-Regel, eine Anwendung wird temporär freigeschaltet, eine Zusatzverbindung wird für ein Projekt eingerichtet, eine Wartungsadresse wird aus dem Regelwerk ausgenommen. Jede einzelne Ausnahme ist für sich nachvollziehbar und oft auch begründet – problematisch wird die Summe, wenn sie nicht zurückgesetzt und nicht dokumentiert wird. Im laufenden Betrieb sind die ursprünglichen Hintergründe nicht mehr rekonstruierbar, und die Security-Architektur zerfällt in eine Sammlung lokaler Entscheidungen. Auditierbarkeit und Nachvollziehbarkeit leiden lange bevor es zu einem Vorfall kommt, weil kaum noch entscheidbar ist, welche Regel bewusst so gesetzt wurde und welche nur historisch besteht.
Folgen:
Im laufenden Betrieb entsteht ein unübersichtliches Regelwerk, das sich kaum noch konsolidieren lässt
Das ursprüngliche Security-Konzept wird schleichend unterlaufen, ohne dass ein einzelner Verantwortlicher die Ursache benennen kann
Neue Audits decken Abweichungen auf, deren Hintergrund nicht mehr rekonstruierbar ist
Änderungen an zentralen Regeln werden riskant, weil nicht vorhersagbar ist, welche lokale Ausnahme dadurch bricht
Die Verantwortung für Ausnahmen ist unklar und wechselt mit personellen Veränderungen, ohne dass eine Übergabe dokumentiert wäre
Die Wiederherstellung eines definierten Zustands nach einem Vorfall ist schwieriger, weil der Soll-Zustand nicht eindeutig festgeschrieben ist
BEKOM Cloud versieht jede Ausnahme mit Ablaufdatum, Verantwortlichem und Begründung und prüft sie regelmäßig im Change-Prozess.
VPN ohne Identity-Kontrolle
Ein dritter Fehler ist die Gleichsetzung von VPN-Zugang mit Netzwerkberechtigung. Wer den VPN-Client erfolgreich aufbaut, gilt als vertrauenswürdig und erhält Zugriff auf Ressourcen innerhalb der Vertrauenszone. Dieses Modell funktioniert, solange keine Identitäten kompromittiert werden und alle Endgeräte gepflegt sind. Bei einem gestohlenen Gerät, einem kompromittierten Passwort oder einer erfolgreichen Phishing-Attacke wird der Angreifer jedoch behandelt wie ein legitimer Nutzer – inklusive Bewegungsfreiheit im internen Netz. Solche Vorfälle sind nicht ungewöhnlich, und das reine VPN liefert keine Mittel, um sie im Betrieb einzugrenzen.
Folgen:
Kompromittierte Zugänge erhalten vollen Zugriff innerhalb der vertrauten Netzzone
Bewegungen innerhalb des Netzes lassen sich ohne Identity-Kontrolle schwer eingrenzen und noch schwerer nachvollziehen
Die Reaktion im Ernstfall ist aufwendig, weil Sitzungen nicht granular pro Nutzer und Anwendung getrennt sind
Gerätezustand, Standortkontext und Nutzerrolle fließen nicht in die Zugriffsentscheidung ein
Eine nachträgliche Einführung von Identity-first Access erfordert Änderungen an Anwendungen, Netzwerk und Betriebsprozessen parallel
Protokolle der VPN-Sitzungen ersetzen nicht die rollenbezogene Nachvollziehbarkeit, die Audits und Forensik erwarten
Identity-first Access mit Multifaktor-Authentifizierung und Kontextregeln adressiert genau diese Lücke und wird in BEKOM Cloud von Anfang an als Standard eingerichtet.
Kostentreiber bei eigenverantwortlicher Standortanbindung
Die Kostenstruktur bei eigenverantwortlicher Standortanbindung wird durch mehrere variable Aufwände bestimmt: Netzwerk-Engineering für VPN-Konfiguration und SD-WAN-Setup über unterschiedliche Provider-Landschaften, kontinuierliche Überwachung der Verbindungsqualität zwischen Standorten und Cloud-Kern, sowie spezialisierte Zero-Trust-Expertise für sichere Remote-Access-Szenarien.
Besonders Troubleshooting bei standortübergreifenden Performance-Problemen bindet qualifizierte Ressourcen unplanbar. Die BEKOM-Monatspauschale für Standortanbindung umfasst das komplette Engineering aller Verbindungstypen, proaktive Monitoring-Services und die Betreuung sowohl klassischer VPN- als auch moderner Zero-Trust-Architekturen. Durch diese planbare Kostenstruktur entfallen interne Kostentreiber für Netzwerk-Spezialwissen und die operative Betreuung komplexer Standortverbindungen. → Managed Network · Für Lead-Gen-Themen zum Standort-Rollout siehe Rollout & Migration in Stufen.
Häufige Fragen zur Standortanbindung
Welches Anbindungsmodell eignet sich für kleinere Vertriebsbüros?
Für Vertriebsbüros mit überschaubarer Nutzeranzahl und dem Schwerpunkt auf Kommunikations- und Office-Anwendungen ist Site-to-Site VPN über vorhandene Internetanschlüsse der Standard. Die Einrichtung ist reproduzierbar, die Kosten bleiben planbar, und die Performance reicht für typische Anwendungsprofile dieser Standortgröße aus. Für Standorte mit mehreren Internetanschlüssen oder höheren Verfügbarkeitsanforderungen prüft BEKOM im Assessment, ob SD-WAN einen zusätzlichen Nutzen liefert. Die Entscheidung fließt in den Blueprint des jeweiligen Standorts ein.
Wie wird die Verbindung zum DE-Kern abgesichert?
Jede Verbindung zwischen Standort und zentralem Cloud-Kern in Deutschland läuft über verschlüsselte Tunnel mit aktuellen kryptografischen Verfahren. BEKOM konfiguriert die Endpunkte so, dass Schlüssel regelmäßig rotiert werden und nur geprüfte Algorithmen zum Einsatz kommen. Zusätzlich wird der Tunnel-Endpunkt am Standort härtungsgerecht konfiguriert, mit deaktivierten nicht benötigten Diensten und zentraler Protokollierung. Die Konfiguration ist dokumentiert und wird im Change-Prozess gepflegt.
Was bedeutet „dediziertes Unternehmensnetz" im laufenden Betrieb?
Praktisch bedeutet es, dass alle Netzwerkeinstellungen – Routing, Firewall-Regeln, Monitoring-Regeln – für das eigene Unternehmen separat konfiguriert und gepflegt werden. Änderungen wirken nur im eigenen Netz. Die Protokolldaten sind kundenspezifisch und stehen für Audits und Nachweise direkt zur Verfügung, ohne Mandantenabgrenzung. Bei Sicherheitsuntersuchungen oder Datenschutzauskünften entfällt der Aufwand, relevante Daten von den Daten anderer Kunden abzugrenzen.
Welche Umstellung ist bei bestehender VPN-Infrastruktur nötig?
BEKOM prüft im Standort-Assessment, ob vorhandene VPN-Endpunkte, Router und Firewalls mit der Zielarchitektur kompatibel sind oder ob eine Umstellung auf neue Geräte sinnvoller ist. Maßgeblich sind Alter und Unterstützungsstatus der Hardware, die genutzten kryptografischen Verfahren und die Integration in das zentrale Monitoring. In vielen Fällen entsteht ein gemischtes Bild: Einige Standorte werden auf neue Endpunkte umgestellt, andere behalten ihre Hardware mit angepasster Konfiguration.
Wie funktioniert die Anbindung bei Homeoffice und mobilen Nutzern?
Homeoffice-Arbeitsplätze werden nicht über Standort-VPN angebunden, sondern über einen separaten Client-Zugang mit Identity-first Access. Jeder Nutzer meldet sich mit zentraler Identität an, Multifaktor-Authentifizierung ist verpflichtend, und die Zugriffsregeln richten sich nach Rolle, Gerät und Kontext. Am Standort gilt eine zonenbasierte Struktur für Netzwerkzugriffe, am Homeoffice-Arbeitsplatz gilt sie pro Nutzer-Sitzung. Beide Modelle folgen dem Zero-Trust-Prinzip.
Was passiert bei einem Ausfall der Internetverbindung eines Standorts?
Bei SD-WAN-Anbindung mit zwei Leitungen erfolgt die Umschaltung automatisch zur verbleibenden Leitung. Bei reiner Site-to-Site-VPN-Anbindung hängt das Verhalten von der lokalen Redundanz ab: Ist nur eine Leitung vorhanden, stehen standortbezogene Dienste bis zur Wiederherstellung nicht zur Verfügung. Zentrale Dienste bleiben für andere Standorte unverändert erreichbar. BEKOM informiert im Assessment darüber, welche Redundanzstufe pro Standort sinnvoll ist und welche nicht.
Wie werden länderspezifische Netzwerkanforderungen berücksichtigt?
Manche EU-Länder haben spezifische Anforderungen an Protokollierung, Verschlüsselung oder Datenhaltung. Diese werden im Blueprint des jeweiligen Standorts erfasst und in die lokale Konfiguration übernommen. Die zentrale Governance bleibt einheitlich, die standortspezifischen Ergänzungen sind dokumentiert und werden im Change-Prozess gepflegt. Für Datenschutzgrundlagen und die Einordnung in die DSGVO siehe Compliance-Leitfaden aus dem Silo Mittelstand.
Welche Kosten entstehen bei wachsender Standortanzahl?
Die Kosten skalieren nicht linear mit der Anzahl der Standorte, sondern orientieren sich am Leistungsumfang pro Standorttyp. Ein Vertriebsbüro mit Standard-Blueprint verursacht andere Kosten als ein Produktionsstandort mit dediziertem Anschluss oder SD-WAN. Die Kostenstruktur wird im Assessment pro Standort dokumentiert und bei der Anbindung weiterer Standorte fortgeschrieben. Änderungen durchlaufen den Change-Prozess mit transparenter Darstellung der Budgetauswirkung vor der Umsetzung.
Nächster Schritt: Standort-Assessment anfragen
Der Einstieg in eine sichere Standortanbindung beginnt mit einem Standort-Assessment. BEKOM erfasst die vorhandenen Standorte, die lokalen Netzwerkanforderungen und die Sicherheitsziele und erstellt daraus einen konkreten Anbindungsplan pro Standort, der in die Stufenplanung übergeht.
Ein Assessment zur Standortanbindung liefert eine strukturierte Bestandsaufnahme der aktuellen Netzwerkarchitektur zwischen Ihren Euroraum-Standorten und dem geplanten Cloud-Kern. BEKOM erstellt eine konkrete Empfehlung, welche Verbindungstypen – VPN, SD-WAN oder Zero Trust – für jeden Standort optimal geeignet sind, basierend auf Nutzerzahl, Anwendungsprofil und lokaler Infrastruktur. Das Service-Design definiert die technische Architektur-Empfehlung für eine einheitliche und betriebssichere Standortvernetzung.
Bestandsaufnahme der Netzlandschaft
BEKOM erfasst gemeinsam mit der IT-Leitung die vorhandenen Standorte, Internetanschlüsse, Netzwerkgeräte und die aktuelle Segmentierungslogik. Ergebnis ist eine strukturierte Bestandsliste, die als Grundlage für die Anbindungsentscheidung pro Standort dient.
Anbindungsplan pro Standorttyp
Auf Basis der Bestandsaufnahme entsteht ein Anbindungsplan: welches Modell pro Standort (VPN, SD-WAN oder dedizierte Leitung als Ergänzung), welche Zonen definiert werden und wie die Security-Policies zentral gepflegt werden.
Pilotierung und Rollout
Der Plan wird an einem Pilotstandort umgesetzt, der als Blaupause für die weiteren Standorte dient. Die Ergebnisse fließen in die Stufenplanung für die verbleibenden Standorte ein und werden im laufenden Betrieb dokumentiert.