Planung Internet/Cloud-Zugang
Interessanterweise haben alle Kunden immer wieder die gleichen Fragen an mich gestellt und ich geben hier daher meine Überlegungen zum Stand 2021 wieder. Zuerst muss ich definieren, welche Dienste wie genutzt werden und welche anders.
Alle ist HTTPS
Ich unterscheide da zuerst einmal bezüglich HTTP:
- Zugriffe auf eigene Webseiten
die können Intern zu Intern angesprochen werden
Aber auch Extern (Home-Office) mit und ohne VPN - Zugriffe auf „befreundete Dienste“
das ist z.B. ihr Office 365 Tenant aber auch Salesforce, ServiceNow, DATEV und andere Cloud Dienste - Sonstiges Internet
Da muss der Schutz maximal sein bzw. einige Adresse und Dienste dürfen z.B. gar nicht genutzt werden
Und dann kommt nun natürlich die Frage, wie sie den Zugriffe steuern wollen und müssen. Auch hier gibt es mehrere Wege pro Dienst, z.B.
- „Zentral Proxy“
Das war früher „üblich“ aber skaliert heute nicht mehr, wenn man dezentrale Standorte und Homeoffice macht - Dezentrale Proxy
Wenn die Niederlassungen „groß genug“ sind, dann kann auch jeder Niederlassung ihren Proxy mit Breakout bekommen. Aber das geht ins Geld, ist aufwändig und hilft nicht bei Home-Office. Der lokale Internet Breakout beim Proxy kommt ja nicht dazu - CloudProxy
Verschiedene Dienstleister nehmen ihnen den Proxy-Betrieb gerne ab (z.B. Zscaler u.a.) und betreiben weltweit viele Proxy-Server. Sie könne natürlich auch selbst einen Proxy-Server z.B. in Azure oder einer geeigneten Colocation platzieren und ihre Clients für externe Dienste über diese Systemen zwingen. Sei es per ProxyPAC oder VPN o.ä. Es ist aber auch nicht immer einfach und die Kosten sind zu bewerten - Ohne Proxy
Zuletzt könnten Sie auf den Proxy komplett verzichten, wenn auf dem Client eine passende Software ist, die Zugriffe überwacht und reglementiert. Mit DefenderATP kann ich als Admin z.B. zentral sehen, welche Dienste jemand nutzt und die Dienste sogar unterbinden. Natürlich ist dies auch mit Kosten (M365 Security, M365 E5 etc.) verbinden. Da werden aber andere wieder sagen, dass Kontrolle auf dem Client nicht sicher ist und Malware , speziell wenn der Anwender noch Admin ist und diese aushebeln kann.
Es könnte ja auch auf eine Mischform hinauslaufen, z.B.
- Zugriffe auf eigene Services werden per
VPN oder Zertifikat abgesichert
Wer noch lokale Server selbst betreibt, sollte sich überlegen, wie er diese gegen Angriffe schützt. Selbst ein eigener VPN-Zugang mit "Benutzername/Kennwort" ist eigentlich nicht mehr sicher genug und zumindest ein Risiko zu Kennwort Phishing. Wenn nur ihre eigenen Clients drauf zugreifen, könnte Eine Authentifizierung per Zertifikat eine Option sein. Oder Sie schalten einen Azure AD Application Proxy als Reverse Proxy davor mit PreAuth - Zugriffe auf Office 365 oder andere
vertraute Cloud-Dienste
Wenn wir davon ausgehen, dass diese Dienste alle eine "sichere Authentifizierung" erfordern, dann können Sie sich eine eigene Steuerung auf einem HTTP-Proxy auch einsparen. Wenn Sie den Diensten an sich vertrauen und z.B. ihrem eigenen Tenant am DNS-Namen erkennen, können Sie diese Zugriffe auch „direkt“ durchlassen, d.h. IP-Routing zum nächsten Breakout mit Split-DNS. - Alle anderen Zugriffe leitet man über
einen Proxy (zentral, Dezentral oder Cloud)
Natürlich müssen Sie ihre Anwender vor den Risiken des "Internet" schützen. Aber nicht nur Anwender sondern auch Server sind hier schutzbedürftig, damit nicht eine Webshell "nach hause" telefoniert. Das kann ein HTTP-Proxy sein oder auch eine Clientsoftware
Es gibt kein „richtig“ oder falsch. Man muss einfach mal sehen, wie das WAN (MPLS, SDWAN o.ä.) den Internetzugang bereitstellt.
- Überall lokale dezentrale Ausgänge
Das ist aus Sicht von Office 365 und Microsoft das Ziel aber ihre eigenen Anforderungen kann Microsoft ja nicht wissen. Viele dezentrale Ausgänge sind auch mit Kosten für Router, Konfiguration und Betrieb verbunden. - Oder man routet es über das eigene Wan
zum zentralen Ausgang in der Firma
Das ist der alte Ansatz, der für Office 365 nicht optimal ist und zudem ihre eigenen WAN-Leitungen mit Verkehr belastet, den sie schon früher "auslassen" könnten. - Sie routen es über das eigene Wan zum
zentralen Ausgang in Azure, oder einer
Colocation
Dies bietet sich an, wenn sie ihre WAN um einen "Internet Ausgang" erweiteren können. Verschiedene MPLS/SD-WAN-Betreiber ermöglichen dies, damit der Internet-Traffic der Niederlassung nicht erst zum bislang zentralen Ausgang in der Zentrale muss und dort auch noch kostbare MPLS-Bandbreite kostet. Teilweise wird die Datenmenge "zum Internet" sogar noch abweichend berechnet oder im einer anderen QoS-Klasse versehen.
Letztlich ist es eine Abwägung von Kosten und Nutzen. Aus Office 365-Sicht „reicht“ es Microsoft einfach, den schnellsten direkten Weg zu wählen. Wenn Sie aber einen Internetprovider an einem Standort haben, der nicht gut an Office 365 angebunden ist, dann kann es doch eine Option sein, den ersten Teilweg noch durch das eigene Netzwerk zu gehen. Das gilt natürlich auch, wenn Sie an dem Standort noch gar kein Internet Breakout haben und der erste eingerichtet werden müsste und der Standort eher klein ist.
Audio/Video
Leider, oder zum Glück ist nicht nicht alles HTPS. Audio- und Video-Daten sollten nicht in TCP-Pakete und erst recht nicht in HTTPS-Pakete verpackt werden, da das TCP-Protokoll Paketverluste "repariert" und dazu den Datenstrom anhält, bis die fehlenden Daten angekommen sind. Für "Dateien" ist das essentiell aber für Sprache und Bild ist es besser, die Pakete einfach zu verlieren. Nachlieferungen macht einfach keinen Sinn, denn die Zeit ist ja schon weiter gelaufen.
Das ideale Protokolle für Audio/Video ist "UDP" und das ist leider nicht über einen HTTP-Proxy möglich. Hier müssen Sie losgelöst vom "Surf-Traffic" ihre eigenen Lösungen finden. Es gibt auch hier mehrere Anwendungsfälle.
- Client spricht 1:1 mit anderem Client intern
Wenn sich die Endpunkte direkt erreichen können, versuchen die Clients es auch direkt. Im LAN ist das optimal. Über das eigene WAN kann es schon kritisch werden und mit lokalen Breakouts kann es sogar interessant sein den internen Verkehr zu blockieren und die Clients "über das Cloud-Relay" zu zwingen. Dazu muss IP-Routing, Firewall und lokaler Breakout natürlich richtig funktionieren - Client spricht 1:1 mit anderem Client "extern"
Die beiden Endpunkte könne sich in dem Fall nicht direkt über geroutete IP-Adressen erreichen. Sie werden über das TransportRelay der Cloud geleitet. und je nach Standort der Clients müssen die UDP-Pakete einen Weg nutzen. Direkt ist optimal aber wenn dies unterbunden ist, dann fällt Teams schon mal auf TCP oder gar HTTP zurück. - Client nutzt ein Meeting
In dem Fall senden alle Meeting-Teilnehmer ihre Töne/Bilder an die Konferenzzentrale in der Mitte. Und die steht nun mal in der Cloud bei Microsoft. Hier sollt der Client idealerweise den kürzesten Weg nehmen.
Bezüglich RTP für Audio/Video ist es quasi immer die beste Empfehlung, über möglichst lokale Breakouts zu gehen und die Umwege zu minimieren. Ein HTTP-Proxy hilft hier nicht weiter.