Die Nutzer in den Unternehmen arbeiten in der Regel von der Zentrale oder der Niederlassung aus. Sie kommunizieren über interne Verbindungen via LAN und WAN mit den IT-Ressourcen im Rechenzentrum und mit dem Internet. Logisch befinden sich diese Nutzer innerhalb des Security-Perimeters des Unternehmens und werden von Firewalls geschützt. Die Kommunikation der meisten Unternehmen mit dem Internet erfolgte in den vergangenen zehn Jahren dabei nicht direkt, sondern aus Sicherheitsgründen über Proxyserver. Diese arbeiten prinzipiell als Kommunikationsschnittstelle im Netzwerk, die zwischen zwei Computersystemen vermittelt. Grundlegende Aufgabe des Proxyservers ist es, Clientanfragen an einen Server stellvertretend entgegenzunehmen und mit der eigenen IP-Adresse an den Zielrechner weiterzuleiten. Bei dieser Art der Kommunikation besteht also keine direkte Verbindung zwischen Absender und Empfänger.

In der Regel wissen das anfragende System und der Zielrechner gar nicht, dass sie es mit einem Proxy zu tun haben. Proxyserver lassen sich in zwei Richtungen realisieren. Kommt ein Forward-Proxy zum Schutz des Clients als Schnittstelle zwischen einem privaten Netzwerk und dem Internet zum Einsatz, lassen sich lokale Endgeräte effektiv von Einflüssen aus dem öffentlichen Netz abschirmen. Anfragen aus dem LAN nimmt der Proxy entgegen und leitet sie mit dessen IP-Adresse als Absender an den Zielrechner im Internet weiter. Antwortpakete aus dem Netz werden somit nicht an den Client im LAN adressiert, sondern passieren ebenfalls den Proxyserver, bevor Sie das Ziel erreichen.

In der Regel fungiert der Proxyserver dabei als Kontrollinstanz. Entsprechende Sicherheitssysteme müssen so nicht auf jedem Client des Netzwerks installiert werden, sondern lassen sich auf einer überschaubaren Anzahl an Proxyservern realisieren. Auch Webserver lassen sich zusätzlich absichern, indem ein Reverse-Proxy bei Zugriffen aus dem öffentlichen Netz vorgeschaltet wird. Clients aus dem Internet greifen somit nicht direkt auf den Zielrechner zu. Stattdessen nimmt der Proxyserver die Anfragen an, überprüft sie gemäß konfigurierter Sicherheitsregeln und leitet sie bei Unbedenklichkeit an den Webserver im Hintergrund weiter.

Es gibt diverse Gründe, einen Proxyserver zu implementieren. Als Bindeglied ermöglicht diese Netzwerkkomponente selbst dann einen Datenaustausch zwischen zwei Systemen, wenn eine direkte Verbindung aufgrund inkompatibler IP-Adressen unmöglich ist – beispielsweise weil eine Komponente IPv4 verwendet und die anderen den neuen Standard IPv6. Daten, die den Umweg über einen Proxy nehmen, lassen sich zudem filtern, zwischenspeichern und im Rahmen eines Loadbalancings auf verschiedene Zielsysteme verteilen. Darüber hinaus ist ein Proxy eine zentrale Komponente der Firewall, die Computersysteme vor Angriffen aus dem öffentlichen Netz schützt.

Neben einer allgemeinen Proxy-Definition kursieren diverse Bezeichnungen für verschiedene Arten von Proxyservern, die sich oft nicht trennscharf voneinander abgrenzen lassen. Sie beziehen sich auf die technische Realisation der Netzwerkkomponente sowie auf anwendungsbezogene Unterschiede. Gängig ist eine Klassifikation in Circuit-Level und Application-Level sowie in dedizierte und generische Proxyserver.

Manche Proxyserver sind technisch so realisiert, dass sie in der Lage sind, Datenpakete zu analysieren, die ihnen zur Weiterleitung übergeben werden. Andere Proxy-Implementierungen hingegen haben keinen Zugriff auf Paketdaten. Filterfunktionen lassen sich in diesem Fall jedoch auf Grundlage der Absender-IP-Adresse und des angesprochenen Ports umsetzen. Der Application-Level-Proxy ist auf der Anwendungsschicht (Schicht 7) des OSI-Referenzmodells angesiedelt. Somit verfügt dieser Proxy über Funktionen, um Datenpakete zu analysieren und je nach vorkonfigurierten Regeln zu blockieren, zu verändern und weiterzuleiten. Ein Application-Level-Proxy wird auch Applikations- oder Anwendungsfilter genannt.

Ein Circuit-Level-Proxy arbeitet auf der Transportschicht (Schicht 4) des OSI-Referenzmodells und ist somit nicht in der Lage, Paketdaten zu analysieren. Diese Proxy-Art wird in der Regel als Firewall-Filtermodul eingesetzt und ermöglicht es, Datenpakete über Ports und IP-Adressen zu filtern. Anders als der Application-Level-Proxy kann der Circuit-Level-Proxy die Kommunikation selbst nicht beeinflussen. Stattdessen beruht die Filterung auf dem Alles-oder-nichts-Prinzip

– Datenpakete werden entweder durchgelassen oder blockiert.

Kommt im Unternehmen Microsoft 365 zum Einsatz, ergeben sich auf dem Weg zwischen dem Anwender und M365 eine Reihe von Barrieren: Firewalls, Proxyserver, Router mit Portfilter und andere Systeme. M365 stellt einige Anforderungen an eine Firma, da gerade die Zugriffe auf Exchange Online und SharePoint eine deutliche Verlagerung von Datenflüssen mit sich bringen. Informationen, die bislang im LAN von Clients zum Server übertragen wurden, müssen nun durch die Firewall und das Internet. Daher empfiehlt Microsoft einen lokalen Breakout und lokales DNS. Internetzugriffe von Niederlassungen sollten nicht über das eigene WAN zur Zentrale führen. Latenzzeit stört zudem und ein zwischengeschalteter Proxy bietet Authentifizierung, das Aufbrechen von SSL oder Malwarefilter, die aber für den Zugriff auf die eigenen Daten gar nicht erforderlich sind. Beim Zugriff auf interne Server gab es auch keine Notwendigkeit. Daher mit NAT, aber ohne Proxy.

Die in der DMZ eingesetzten Proxys sollten darüber hinaus noch folgende Funktionen bieten:

-Zulassen von M365-Verkehr zum eigenen Tenant: Hierzu könnte eine Firewall einfach die IP-Adressen der Office 365 passieren lassen. Eine Unterscheidung nach Diensten wäre wünschenswert. Eine Trennung nach Tenants ist allein anhand der IP-Adressen aber nicht möglich.

-Blockieren von Daten aus fremden Tenants: Das ist schon eine größere Herausforderung, da beispielsweise alle Tenants die Adresse und den Namen "outlook.office365.com" als Endpunkt in der Cloud nutzen. Für SharePoint ist es eher möglich, da hier der Tenant-Name mit in den URLs und beim "Client-Hello" enthalten ist. Eine pfiffige Firewall kann sehr wohl zwischen Zielen anhand des TLS-Handshakes unterscheiden, wobei diese Funktion mit TLS 1.3 entfällt.

-RTP-Support: Damit Audio und Video von Skype for Business und Teams optimal übertragen werden, sollte die Firewall natürlich eine Kommunikation über den Portbereich 3478 bis 3481 (UDP) erlauben. Ideal wäre es, wenn die Firewall die Payload betrachtet, um Audio und Video anhand des RTP-Headers zu erkennen, um so etwas zusätzliche Sicherheit zu bieten – aber vor allem auch, um eine aussagekräftige Nutzungsstatistik zu liefern.

Da M365 ausschließlich über das Internet erreichbar ist, erfolgt der Zugriff aus dem LAN auf M365 über die ISA via der normalen Sicherheitsinfrastruktur. Daher müssen Sie einige Ausnahmeregelungen auf Policy-Ebene für den Zugriff auf M365 (etwa SSL-Interception) festlegen. Da derzeit keine expliziten Proxys für M365 existieren, bestehen auch keine Möglichkeiten der Verkehrsflusssteuerung in der DMZ. Die lokalen IT-Ressourcen im Rechenzentrum (private Cloud) werden derweil wie üblich an die Kommunikationsinfrastruktur angebunden und die Nutzer können über die RZ-Zugänge mit den benötigten Anwendungen kommunizieren.

Die Anforderungen der Digitalisierung sowie ein geändertes Anwenderverhalten führen dazu, dass IT-Dienste sowohl im lokalen Rechenzentrum als auch in der Public Cloud bereitgestellt werden. Auf diese Weise entstehen Hybrid- und Multicloud-Architekturen, die die Vorzüge beider Welten vereinen und neue Wettbewerbspotenziale bereitstellen.

Eine hybride Cloud bezieht sich auf eine Kombination aus verschiedenen Arten von Infrastrukturen, in der Regel eine Public Cloud mit einer On-Premises- oder Private-Cloud-Infrastruktur. Die hybride Cloudarchitektur ist eine Orchestrierung von lokalen Private Clouds mit Public-Cloudplattformen von Drittanbietern. Die Hybrid Cloud bietet Unternehmen mehr Optionen für die Datenbereitstellung und mehr Flexibilität, da sie die Verschiebung von Workloads zwischen Public und Private Clouds ermöglicht, wenn sich Kosten und Rechenanforderungen ändern. Je nachdem, wen Sie fragen, können Hybrid Clouds daher Folgendes umfassen:

-Mindestens eine Public und mindestens eine Private Cloud,

-zwei oder mehr Private Clouds,

-zwei oder mehr Public Clouds,

-eine virtuelle oder Bare-Metal-Umgebung, die mit mindestens einer Cloud (Private oder Public) verbunden ist.

Die wichtigste Erkenntnis besteht darin, dass der Begriff "Hybrid" sich nicht auf eine traditionelle IT-Infrastruktur bezieht, auf die eine Cloudkonnektivität aufgeschraubt wird. Es handelt sich um die Nutzung von zwei Cloudinfrastrukturen. Außerdem ist die Portabilität von zentraler Bedeutung, da die Flexibilität der Daten und die Arbeitsbelastung entscheidend sind, um den vollen Nutzen zu erzielen. Das bedeutet, dass Sie die Möglichkeit haben müssen, beide Umgebungen nahtlos für einen einzigen Arbeitsablauf zu nutzen. Unabhängig von der Art der Einrichtung haben alle Hybrid-Cloud-Architekturen einige gemeinsame Merkmale:

-Datenintegration: Die Daten des Unternehmens werden über eine öffentliche und nicht-öffentliche Infrastruktur synchronisiert. Durch die Synchronisierung über die verschiedenen Infrastrukturen hinweg müssen Sie zusätzliche technische Lösungen implementieren, um die Daten automatisch konsistent zu halten.

-Einheitliche Verwaltung: Im Idealfall verwaltet ein übergreifendes Tool die hybride Cloudinfrastruktur und macht so ein separates Cloudmanagement überflüssig. Der getrennte Betrieb von mehreren Clouds ist schwierig, da jede Cloud unterschiedliche APIs und SLAs benötigt und unterschiedliche Funktionen und Fähigkeiten bereitstellt.

-Netzwerkverbindungen: Öffentliche oder private Clouds und klassische Infrastrukturen sind entweder über ein privates Netzwerk oder das öffentliche Internet verbunden. Die Netzwerkkonnektivität ist entscheidend für den Einsatz einer Hybrid-Cloud-Architektur.

-Konsolidierung der IT-Ressourcen.

-Orchestrierung von Prozessen mit Automatisierung.

In einer Multicloud-Architektur nutzen Unternehmen mehrere unterschiedliche Public-Cloud-Dienste von verschiedenen Anbietern. Eine Multicloud-Architektur spiegelt die wachsende Erkenntnis wider, dass nicht alle Clouds gleich ausgestaltet sind. Zum Beispiel hat eine Vertriebs- und Marketingabteilung andere Anforderungen an die Datenverarbeitung als die Softwareentwicklung oder die Forschungsabteilung. Eine Multicloud-Architektur gibt den Unternehmen auch zusätzliche Sicherheit, da diese die Abhängigkeit von einem einzelnen Anbieter minimiert, was oft die Flexibilität erhöht und die Kosten senkt.

Für die dargestellten Office-365-Dienste waren bisher keine Security-Funktionen verfügbar. Diese werden in diesem Szenario dadurch möglich, dass die Office-365Kommunikation über ein separates Sicherheits-Gateway die Kommunikation zu anderen Clouddiensten via Direct Connect, Express Route et cetera realisiert. Beim Zugang zu den Cloudressourcen handelt es sich somit nicht mehr um einen Breakout ins Internet, sondern um eine Art "Kabel" zu einem erweiterten Data Center.

Um den Datenverkehr abzusichern, bietet sich ein Secure-Cloud-und-VPN-Connectivity-Gateway an. Es hat die Aufgabe, die Kommunikation zu den Clouddiensten (Direct Connect, Express Route et cetera) zu schützen, in der Regel per VPN und den zugehörigen Zugriffsrechten.

Zahlreiche Firmen nutzen ein VPN, um ihren Mitarbeitern einen sicheren Fernzugriff auf die internen Ressourcen des Unternehmens zu ermöglichen. Ein virtuelles privates Netzwerk dient also dazu, die Sicherheit eines Unternehmensnetzwerks und der Mitarbeiter, die sich damit verbinden müssen, zu erhalten. Dazu kommt ein Tunneling-Protokoll zum Einsatz, um die übertragenen Daten zu verschlüsseln und geschützt vor fremden Blicken von einem System zu einem anderen zu senden. Ein VPN-Tunnel sichert folglich alle Daten, die zwischen dem Computer eines Mitarbeiters und dem entfernten VPN-Server des Arbeitgebers übertragen werden.

Der Client im Home Office wird dabei über ein VPN-Gateway umgeleitet. Dies gilt sowohl für den Zugriff auf interne Resourcen als auch den Zugriff auf M365 über einen ISA-Server (Internet Security and Acceleration). In diesem Fall ist von Backhauling und Hairpinning die Rede. Unter einem Backhaul ist die Anbindung einer am äußeren Rand des Netzwerks befindlichen Netzwerkkomponente an das innere Netzwerk zu verstehen. In einem solchen hierarchischen Kommunikationsnetz umfasst der Backhaul die Zwischenverbindungen zwischen dem Kernnetz oder Backbone-Netz und den Home Offices.

Die meisten Unternehmen nutzen zusätzlich eine Architektur, die auf das Hairpinning des Datenverkehrs setzt. Bei der Methode gelangt ein Paket zu einer Schnittstelle in Richtung Internet, aber anstatt weiterzugehen macht es eine "Haarnadelkurve" und kommt über dieselbe Schnittstelle wieder herein. Das klassische Szenario ist das Home Office, in das kein Datenverkehr ein- oder ausgehen sollte, ohne vorher einer Sicherheitsprüfung unterzogen zu werden. Die Bereitstellung eines eigenständigen Sicherheits-Stacks in Dutzenden oder gar Hunderten von Home Offices könnte eine praktikable Strategie sein, wäre aber aus Sicht der Kosten, der Komplexität und des Verwaltungsaufwands ein Alptraum.

Stattdessen wird der Ansatz bevorzugt, alle Clientanfragen an das Internet vom Home Office aus an einen zentralen Ort, etwa das Rechenzentrum, zu leiten, wo die Sicherheit durchgesetzt wird, und erst dann – nach einer Überprüfung – fließt der Datenverkehr in Richtung Internet. Das Gleiche gilt für die Anforderung von Webinhalten oder die Interaktion mit einer geschäftskritischen SaaS-Anwendung. Nach der Antwort des Servers muss der Datenverkehr dann denselben Umweg über das Rechenzentrum zurück zur Zweigstelle und schließlich zum Desktop des Benutzers nehmen.

Es bedarf keiner besonderen Netzwerkexpertise, um zu erkennen, dass dieser Ansatz die Benutzerfreundlichkeit beeinträchtigt, Latenzzeiten hinzufügt und die Abläufe erheblich verlangsamt. Abgesehen davon stellt dieser Ansatz auch eine größere Belastung für die teuren und schwer zu wartenden privaten WAN-Verbindungen wie MPLS dar, auf die sich Unternehmen lange Zeit verlassen haben, um ihr verteiltes Unternehmen zu verbinden.

Bei einem Split Tunnel wird nur ein Teil des Verkehrs durch den VPN-Tunnel in das Unternehmen geleitet, während andere Bestandteile weiterhin über den lokalen Router und den verbundenen Internet Service Provider (ISP) laufen.

Nehmen wir als Beispiel einen entfernt arbeitenden Mitarbeiter, der eine VPN-Verbindung zwischen seinem Rechner und der Firmenzentrale aufbaut. Über diesen Tunnel wird die gesamte geschäftliche, aber auch private Kommunikation in das Firmennetz geleitet. Die Split-Tunneling-Funktion ermöglicht, dass nur die geschäftlichen Daten über den sicheren VPN-Tunnel laufen. Der private Datenverkehr des Mitarbeiters findet stattdessen über den lokalen Router und seinen ISP den Weg ins Internet. Welche Daten durch das VPN gesendet und welche direkt an den ISP übermittelt werden, hängt vom gewählten VPN-Dienst und dem Unternehmen ab, das ihn nutzt. Administratoren können den Tunnel so konfigurieren, dass er die Daten im Netzwerk überwacht und dann etwa auf Basis der angesprochenen IP-Adressen intelligent entscheidet, welche Route die Datenpakete nehmen sollen.

Das Split Tunneling birgt aus Sicherheitssicht allerdings eine Reihe von Problemen. So können etwa alle Daten, die nicht durch den sicheren VPN-Tunnel laufen, auch nicht durch die Firmen-Firewall geschützt werden. Dasselbe gilt auch für weitere zentral vorhandene Systeme zum Schutz der Endpunkte vor Malware und anderen Gefahren. Die Daten können etwa durch den ISP oder Cyberangreifer eingesehen und abgefangen werden. Remote arbeitende Mitarbeiter, die im Web surfen, sind ebenfalls nicht durch das VPN geschützt. Damit sind sie einer erhöhten Gefahr von Phishing und Malware ausgesetzt. Hinzu kommt, dass ein einmal infizierter Remote-Computer dazu genutzt werden kann, über den aufgebauten VPN-Tunnel und mit den Nutzerdaten des Mitarbeiters auf das Firmennetz zuzugreifen.

VPN-Split-Tunneling wirkt sich zudem negativ auf die Fähigkeiten eines Unternehmens aus, unerwünschtes Filesharing durch die Mitarbeiter zu unterbinden. Das ist besonders dann ein Problem, wenn zu befürchten ist, dass Insider möglicherweise interne Daten extrahieren könnten. Jegliche Maßnahmen, die verhindern sollen, dass brisante Geschäftsdaten ohne Erlaubnis über das VPN geschickt werden, wirken naturgemäß nicht bei den Daten, die über einen lokalen Router laufen. Auch kann es zu Schwierigkeiten bei der Einhaltung von Compliance-Vorgaben eines Unternehmens kommen, weil der über den lokalen Router laufende Verkehr nicht überwacht werden kann.

Eine SASE-Plattform funktioniert durch die Bündelung mehrerer Elemente, also die Kombination von SD-WAN mit Netzsicherheitsdiensten wie

-Firewalls-as-a-Service (FaaS),

-Software-as-a-Service (SaaS),

-Secure Web Gateways (SWG),

-Cloud Access Security Broker (CASB) sowie

-Zero-Trust-Netzwerkzugang

Das Ergebnis ist eine mandantenfähige und multiregionale Sicherheitsplattform, die unabhängig von den Standorten der Mitarbeiter, Rechenzentren, Cloudservices oder Büros vor Ort aktiv ist. SASE verlässt sich nicht auf Inspektions-Engines in Rechenzentren. Stattdessen werden SASE-Inspektionsgeräte zu einem nahegelegenen Point of Presence (PoP) gebracht. Ein SASE-Client – etwa ein mobiles Gerät mit einem SASE-Agenten, ein IoT-Gerät, ein mobiles Gerät mit clientlosem Zugriff oder Zweigstellenausrüstung – sendet den Datenverkehr zur Inspektion und Weiterleitung an den PoP entweder ins Internet oder über die zentrale SASE-Architektur. SASE-Dienste weisen vier entscheidende Merkmale auf:

1. Globaler SD-WAN-Dienst: SASE verwendet einen SD-WAN-Service mit einem privaten Backbone, der Latenzprobleme des globalen Internets vermeidet und die einzelnen PoPs miteinander verbindet, die für Sicherheits- und Netzwerksoftware verwendet werden. Der Datenverkehr berührt nur selten das Internet – und zwar nur, um sich mit dem globalen SASE-Backbone zu verbinden.

2. Verteilte Inspektion und Durchsetzung von Richtlinien: SASE-Dienste verbinden nicht nur Geräte, sondern schützen sie auch. Die Ver- und Entschlüsselung des Inline-Verkehrs ist ein wichtiges Thema. SASE-Dienste sollten den Datenverkehr mit mehreren parallel arbeitenden Engines inspizieren. Zu den Inspektions-Engines gehören Malware-Scanning und Sandboxing. SASE sollte auch andere Dienste anbieten, wie DNS-basierten und DDoS-Schutz. Lokale Vorschriften wie die DSGVO sollten in den Routing- und Sicherheitsrichtlinien der SASE durchsetzbar sein.

3. Cloudarchitektur: SASE-Dienste sollten Cloudressourcen und -Architekturen ohne spezifische Hardwareanforderungen nutzen und keine Dienstverkettung beinhalten. Software sollte aus Kostengründen mandantenfähig sein und für eine schnelle Erweiterung instanziierbar sein.

4. Identitätsgesteuert: SASE-Dienste haben Zugriff auf Grundlagen von Benutzeridentitätskennzeichen wie spezifisches Anwendergerät und Einsatzort.

SASE bietet eine agile und skalierbare Lösung für Netzwerke und Sicherheit im Home Office. Hier ergeben sich zwei wesentliche Anwendungsfälle. Der erste Anwendungsfall ist der Zugriff eines Benutzers im Home Office auf eine SaaS-Anwendung. Dabei arbeitet ein Benutzer von zu Hause aus und will auf eine SaaS-Anwendung (beispielsweise M365) zugreifen. Der User verwendet dafür das von seinem Unternehmen bereitgestellte Endgerät. Der SDWAN-Orchestrator erstellt Sicherheitsrichtlinien für den Secure Access (ZTNA) und die Cloud-Web-Security. Diese Regeln sorgen für weitere Prüfung durch die CloudWeb-Security-Funktionen (beispielsweise CASB, Antimalware, Sandboxing und DLP), bevor die Daten an die SaaS-Anwendung weitergeleitet werden. Die Netzwerk-und Sicherheitsrichtlinien werden vom Orchestrator durchgesetzt. Bei der Übermittlung der Datenströme finden die folgenden Prozessschritte statt:

-Der Benutzer im Homer Office öffnet die Office-365-Anwendung auf dem Endgerät. Nach der Verbindung mit dem Netzwerk baut der Endpunkt eine Sitzung mit dem Secure Access Service auf, der die ZTNA beim SASE-Provider verwaltet. Der Secure Access authentifiziert und autorisiert den Benutzer in seinem Gerätekontext. Bei Erfolg wird ein sicherer Tunnel zwischen dem Endpunkt und dem SASE-Provider aufgebaut.

-Der Benutzer versucht, sich mit der SaaS-Anwendung zu verbinden. Der Secure Access leitet den Datenverkehr an das SD-WAN-Gateway weiter, das den Datenstrom prüft, um dessen Quelle und Ziel zu identifizieren. Hier kommt es auf die globalen Sicherheitsrichtlinien an, die auf der Identität des Benutzers, seiner Gruppenzugehörigkeit und der Zugriffsberechtigungsstufe der Anwendung referenzieren.

-Entsprechend der Sicherheitsrichtlinien leitet die SD-WAN-Komponente von SA-SE-Provider den Datenverkehr an die Cloud-Web-Security weiter, wo zusätzliche Sicherheitsdienste wie CASB, DLP oder Sandboxing zum Einsatz kommen.

-Der Datenverkehr wird anschließend vom SASE-Provider zum endgültigen SaaS-Ziel (M365) geroutet.

In diesem Beispiel verfügt der Nutzer im Home Office nur über seine persönliche Internetverbindung und die dazugehörige Standardhardware. Würde das Home Office über ein SD-WAN-Edge-Gerät verfügen, entspräche das Verkehrsflusssmuster dem Modell eines Zweigstellennutzers.

Im zweiten Anwendungsfall nimmt ein Mitarbeiter im Home Office Zugriff auf eine Anwendung im Rechenzentrum des Unternehmens. Derselbe Benutzer greift dabei auf eine Applikation zu, die sich in einem firmeneigenen Rechenzentrum befindet. Zum Einsatz kommt wieder das vom Unternehmen bereitgestellte Endgerät. Dabei wird eine Sicherheitsrichtlinie vom Orchestrator für Secure Access und die Cloud-Firewall erstellt. Die Regeln werden für eine weitere Prüfung durch Cloud-Firewall-Funktionen wie IDS/IPS, Antimalware und die erweiterte Bedrohungserkennung festgelegt, bevor die zugehörigen Pakete an die Anwendung im Rechenzentrum gehen. Netzwerk- und Sicherheitsrichtlinien werden vom Orchestrator durchgesetzt. Bei der Übermittlung der Datenströme werden die folgenden Prozessschritte ausgeführt:

-Nach der Verbindung mit dem Heimnetzwerk baut der Endpunkt eine Session mit dem Secure Access Service am SA-SE-Provider auf. Der Secure Access authentifiziert und autorisiert den Benutzer und dessen Gerätekontext. Bei Erfolg entsteht ein sicherer Zugangstunnel zwischen dem Endpunkt und dem SASE-Provider.

-Die Secure-Access-Komponente des SASE-Providers leitet den Datenverkehr an die SD-WAN-Gateway-Komponente weiter, die den Datenfluss prüft, um dessen Quelle und Ziel zu identifizieren. Diese wendet Netzwerk- und Sicherheitsrichtlinien an, die auf der Identität des Benutzers, der Gruppenzugehörigkeit und der Berechtigungsstufe basieren.

-Entsprechend der Sicherheitsrichtlinien leitet die SD-WAN-Gateway-Komponente des SASE-Providers den Datenverkehr an die Cloud-Firewall weiter, wo diese individuelle Sicherheitsregeln wie IDS/ IPS, Antimalware oder Advanced Threat Detection auf die Sitzung anwendet.

-Der Datenverkehr verlässt den SASE-Provider und wird über den SD-WAN-Overlay-Tunnel zur Zugangskomponente im Unternehmensnetz beziehungsweise zum Rechenzentrum geleitet.

-Der Verkehr in Rückwärtsrichtung erfolgt auf demselben Weg vom betreffenden Rechner im Rechenzentrum des Unternehmens zurück zum Home Office und dann zum Laptop des Nutzers.

Der Trend hin zu hybriden Arbeitsweisen sorgt dafür, dass die Unternehmen die Möglichkeit haben, eine Sicherheitsplattform aufzusetzen, die unabhängig ist von Standorten, Rechenzentren, Cloudservices oder Büros. Die Vorteile: IT-Dienste lassen sich wesentlich schneller bereitstellen, die Administration für die Netzwerkinfrastruktur wird deutlich vereinfacht und vor allem können Apps und Security kostengünstiger bereitgestellt werden.