Cloud in P-A-P-Umgebungen

Es gibt Kunden, die erhöhte Sicherheitsanforderung haben und sich an den Empfehlungen des BSI zu einer sogenannten P-A-P-Umgebung orientieren.

Was ist P-A-P?

Die Abkürzung P-A-P steht für die Kette aus "Paketfilter - Application Layer Gateway - Paketfilter", über die ein Netzwerk besonders geschützt werden soll.

 Kernkomponenten ist dabei das Gateway, welches idealerweise auf Anwendungsschicht arbeitet und Malware und Angriffe verhindern soll. Damit ist natürlich klar, dass dieses Gateway die Applikation auch verstehen muss und idealerweise auch mit verschlüsselter Umgebung umgehen kann.

  • SMTP = Mailrelay
    Ein klassisches Application Layer Gateway für die Übertragung von E-Mails ist ein SMTP-Relay, welches die Mails auf der einen Seite annimmt, dann definierten Filtern unterwirft und ggfls. nach einer Umschreibung an das nächste System weiter gibt.
  • HTTP-Verkehr
    Auch hier kennen wir schon lange den "HTTP-Proxy", der neben den Schutz auch eine Authentifizierung und Filterung durchführen kann. Die Funktion eines "Cache" ist mittlerweile immer weniger gefragt. Aber ein HTTP-Proxy kann auch SSL-Verbindungen aufbrechen, wenn die Clients dem Stammzertifikat vertrauen und der Service kein Zertifikatspinning fordert.

Das Gateway selbst muss natürlich auch geschützt werden. Dazu sieht das BSI auf beiden Seiten entsprechende Paketfilter vor, die primär IP-Adressen und Ports filter. Da solche Regeln "überschaubar" und recht einfach umgesetzt sind, sollten diese Paketfilter selbst sehr robust gegen Angriffe oder Sicherheitslücken sein. Wenn es um eine Kommunikation von intern nach Extern geht, muss der Paketfilter nur von innen gestartete und etablierte Verbindungen von extern durchlassen. Kniffliger wird es aber nun für Protokolle, die etwas "anders" sind und für die es keine bekannten Proxy-Services gibt.

Wer braucht P-A-P?

Ehe ich aber ein paar Gedanken zu Teams und insbesondere RTP anstelle, sollten Sie überlegen, ob sie diesen Aufwand für jegliche Kommunikation treiben müssen oder ein abgestuftes Konzept zum Einsatz kommt. Wer eigene Dienste bereitstellt, wird sich schon immer überlegt haben, wie er diese Services absichert und ein "Surfen im Internet" kann ein einfacher Proxy durchaus schon absichert. Ein Schutz auf dem Desktop gegen unerlaubt ausgeführt Programme ist eh erforderlich, da es auch andere Einfallstore gibt. Siehe dazu auch Endpoint Security.

Ein einfacher DSL-Router mit NAT ist im Home Office bei den meisten Firmen leider Standard, wenn der Notebook nicht direkt eine UMTS/LTE-Karte hat und damit im Internet ist. Endpoint Security ist auch kein alleine ausreichender Schutz. Aber ich konzentriere mich nun auf die Firmen, die im Bereich der Banken, Versicherungen, KRITIS-Umgebungen, Gesundheit, Militär, Energie, Transport unterwegs sind, und sich an BSI-Vorgaben orientieren oder ihr Netzwerk sogar von einem Auditor "zertifizieren" lassen.

Das Problem hier ist aber, dass es meines Wissens keine harten Fakten gibt und die Aussagen interpretiert werden können. So kommen Sie als Administrator in die wachsweiche Situation, dass Sie ein sicheres Netzwerk aufbauen müssen aber der Auditor am Ende nur sagt, ob es erfüllt ist oder nicht. Sie bekommen aber meist kein Hinweis, was denn noch fehlt. Das soll verhindern, dass Prüfer ihre eigene Empfehlung prüfen. Daher gibt es nur wenige TÜV-Prüfer, die ihnen sagen, wie sie es machen könnten sondern nur warum etwas nicht möglich ist. Daher solle ja auch Buchprüfer nicht parallel Berater der zu prüfenden Gesellschaft sein. Das hat bei WireCard, Flowtex, Comroad und anderen Fällen auch nicht funktioniert.

Ich stehe da schon auf dem Standpunkt, dass jemand, der die Sicherheit eines Netzwerks bewertet, auch klar Farbe bekennen soll, was besser gemacht werden muss. Schließlich hat er hoffentlich schon mehrere Kunden geprüft und sollte sich auskennen.

Bis dahin kann ich mich aber nur auf öffentliche Quellen berufen. Die sind alles andere als "Eindeutig", Es gibt verschiedene Quelle, die teilweise von „MÜSSEN“ aber manchmal auch von „SOLLTEN“ oder „DÜRFEN NICHT“ sprechen. Hier ein paar Zitate:

Eine P-A-P-Struktur, die aus Paketfilter, Application-Layer-Gateway bzw. Sicherheits-Proxies und Paketfilter besteht, MUSS immer realisiert werden, wenn die Sicherheitsrichtlinie oder die Anforderungsspezifikation dies fordern.
Quelle: NET.1: Netze NET.1.1: Netzarchitektur und - design
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs_2021/09_NET_Netze_und_Kommunikation/NET_1_1_Netzarchitektur_und_design_Edition_2021.pdf?__blob=publicationFile&v=2   Seite 4

Das ist eine sehr deutliche Aussage, dass P-A-P umgesetzt werden muss. Allerdings relativiert mit "wenn die Sicherheitsrichtlinie oder die Anforderungsspezifikation". Als Planer muss ich den Ball von der Technik und dem Design erst mal wieder zum CISO oder der IT-Security zurückspielen. Welche Sicherheitsrichtlinie ist denn für die Firma zutreffend, denn letztlich erspare ich mir danach die leidige Diskussion ums liebe Geld.

Aber schon einige Dokumente weiter wird relativiert:

NET.3.2.A16 Aufbau einer „P-A-P“-Struktur (S)
Eine „Paketfilter – Application-Level-Gateway – Paketfilter“-(P-A-P)-Struktur SOLLTE eingesetzt werden. Sie MUSS aus mehreren Komponenten mit jeweils dafür geeigneter Hard- und Software bestehen. Für die wichtigsten verwendeten Protokolle SOLLTEN Sicherheitsproxies auf Anwendungsschicht vorhanden sein. Für andere Dienste SOLLTEN zumindest generische Sicherheitsproxies für TCP und UDP genutzt werden. Die Sicherheitsproxies SOLLTEN zudem innerhalb einer abgesicherten Laufzeitumgebung des Betriebssystems ablaufen.
BSI: NET.3: Netzkomponenten NET.3.2: Firewall - 3.2 Standard-Anforderungen
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs_2021/09_NET_Netze_und_Kommunikation/NET_3_2_Firewall_Edition_2021.pdf?__blob=publicationFile&v=2 

Da steht nach meiner Auffassung ganz viel "SOLLTEN" drin.

„Verbindungen vom ICS-Netz zu externen Netzen (z. B. Office-Netz) sollten ausschließlich über ProxyDienste in der DMZ erfolgen. Direkte Verbindungen zwischen den Netzen müssen verhindert werden. Die Kommunikation mit anderen Netzen sollte komplett unterbunden werden“
Quelle: BSI: ICS-Security-Kompendium Version 1.23 Seite 63 38. Einsatz von Firewallshttps://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ICS/ICS-Security_kompendium_pdf.pdf?__blob=publicationFile

Hier kann man nun streiten, ob ein Office-Netzwerk mit Exchange Online, SharePoint, Teams und anderen Dienste als "Industrie-Netzwerk (ICS)" zu bewerten ist. Es wird ja gerade beschrieben, dass der Übergang vom ICS-Netz zum Office-Netzwerk über Proxy-Dienste zu erfolgen hat.

Etwas deutlicher wird der folgende Absatz:

NET.1.1.A8 Grundlegende Absicherung des Internetzugangs (B)
Der Internetverkehr MUSS über die Firewall-Struktur geführt werden (siehe NET.1.1.A4 Netztrennung in Zonen). Die Datenflüsse MÜSSEN durch die Firewall-Struktur auf die benötigten Protokolle und Kommunikationsbeziehungen eingeschränkt werden.
Quelle IT-Grundschutz | NET.1.1 Netzarchitektur und -design, Seite 4
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs_2021/09_NET_Netze_und_Kommunikation/NET_1_1_Netzarchitektur_und_design_Edition_2021.pdf?__blob=publicationFile&v=2 

Niemand sollte heute seine Systeme ungesichert mit dem Internet verbinden und ich denke wir haben alle eine Firewall, die zwischen den verschiedenen Netzwerkzonen die Verbindungen reglementiert. Hier steht aber nicht von einem Proxy oder Application Layer Gateway sondern erst einmal von einer nicht näher spezifizierten Funktion einer Firewall. Auch ein Paketfilter ist eine Firewall und wenn man dem Vertrieb einiger DSL-Router trauen würden, wäre selbst solch ein Gerät eine Firewall. Es steht natürlich nicht drin, wie umfangreich die Einschränkungen sind.

Ich habe dann auch noch eine Quelle zum Thema VoIP und SBC

Grundsätzlich realisiert der SBC eine Protokollvalidierung für alle übertragenen Daten (Signalisierungs- und Mediendaten), wobei die Kommunikation auch über Network Address Translation (NAT) erfolgen kann.
BSI: Kompendium: Videokonferenzsysteme: KoViKo - Version 1.0.1. 3.2.5 Session Border Controller (Seite 26)
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Kompendium-Videokonferenzsysteme.pdf?__blob=publicationFile&v=4 

Diese Aussage bringt mich beim Thema Teams-Kommunikation zwischen Client und Backend natürlich nicht weiter.

Das Real-Time Transport Protocol (RTP) dient der Übertragung echtzeitsensitiver Daten für Unicast- und Multicast-Anwendungen (siehe [IETF RFC3550-2003]). Vornehmlich wird RTP für die Übertragung von Echtzeitdaten in Form von Sprach- und Videodaten, d. h. den Mediendaten, eingesetzt. RTP setzt auf dem User Datagram Protocol (UDP) auf. Im Gegensatz zu anderen Anwendungsprotokollen, die UDP verwenden, z. B. RADIUS (Remote Authentication Dial-In User Service), werden bei RTP-Sitzungen im Fall von Paketverlusten Daten nicht erneut übertragen. Stattdessen werden Datenverluste und damit verbundene Qualitätsschwankungen bewusst in Kauf genommen, um zu verhindern, dass Delay und Jitter durch ein wiederholtes Senden der Pakete erhöht werden.
Quelle: BSI: Kompendium: Videokonferenzsysteme: KoViKo - Version 1.0.1. 3.4.2 Protokolle (Seite 40/41)
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Kompendium-Videokonferenzsysteme.pdf?__blob=publicationFile&v=4

Viel besser hätte ich es auch nicht schreiben können. Schade nur, dass es keine weiteren Informationen zum Thema Sicherheit von RTP gibt.

Nun war ich natürlich schon etwas verwirrt, denn die ganzen Stellen und andere Dokumente haben den Nebel nicht wirklich gelichtet. Natürlich wird eine größere Firma schon aus Eigeninteresse einen hohen Schutz durch mehrere Firewalls unterschiedlicher Hersteller aufbauen. Sowohl der interne als auch externe Paketfilter ist eine wichtige Komponente, um unerwünschte Verbindungen frühzeitig zu blockieren und die kostbaren Application Layer Gateways gegen allzu viel Störfeuer besser zu schützen. Allerdings habe ich keine "Case Studies" von Firmen oder Artikel gefunden, die übertragen gesagt: "mehr Fleisch an die Knochen bringen".

Ich möchte ihnen aber nicht das Zitat einer Person vorenthalten, die im KRITIS-Umfeld unterwegs ist und die gleichen Herausforderungen beschäftigen.

All das sind „SOLLTE“ Kriterien, die keine einzige KRITIS Struktur einsetzt, die ich kenne. ... wenn HINTER einer SOLLTE Anmerkung ein MUSS steht, dann gilt SOLLTE. Die wollen damit sagen, Beispiel man SOLLTE ein Haus abschließen aber WENN man das macht, dann MUSS man es mit einem Schlüssel machen.
Quelle: <nicht öffentlich>

Office 365 Zone

Die klassische P-A-P-Diskussion beschäftigt sich natürlich mit der Absicherung eines internen Netzwerks gegen das Internet. Meine erste Frage in dem Umfeld wäre:

Zählen die Server und dort hinterlegten Daten on "Office365/Microsoft 365" eigentlich als Internet?

Zugegeben, die Frage ist schon provokativ, aber welches Vertrauen bringe ich meiner Bank entgegen, mit der ich eine Geschäftsbeziehung samt Verträge habe und welche "Schutzfunktion" habe ich im Eigenheim, wenn ich auf dem Weg zur Bank bin? Hier geht es schließlich auch um Werte, deren Verlust nicht vernachlässigt werden sollte.

Es gibt ja durchaus Möglichkeiten den Weg zwischen dem Client und der Cloud so abzusichern, dass die Pakete den sicheren Weg nicht verlassen und auch keine fremden Pakete eingeschleust werden können. Denken Sie an:

  • Express Route
    Mit einem Provider können Sie einen direkten Weg bis zur Eingangstür der Microsoft Cloud aufbauen, so dass die Übertragung qualitätsgesichert (QoS) und geschützt ist
  • Cloud Connect/Express Way
    Selbst ohne eine eigene Leitung haben viele Provider ein direktes Peering mit Microsoft und wenn ihre Daten zwischen ihrem Standort quasi immer über "bekannt" und vertraglich abgesicherte Strecken läuft, könnte man dies als "privates Netz" und nicht mehr "Internet" bezeichnen
  • VPN zu Azure als "Hop" zur Cloud
    eine dritte Option ist ein VPN von ihrem Standort zu einer Gegenstelle in Azure, um so das "unsichere" Internet quasi aussperren.
  • TLS
    Vielleicht brauchen Sie das aber alles gar nicht, da jede Kommunikation mit der Cloud per TLS, (also z:B. HTTPS, SMTPS, POP3S, IMAP4S und SRTP) abgesichert ist. Auch wenn eine Applikation oder ein Service kein "Zertifikat-Pinning" macht, könnte ihre Firewall den Handshake beobachten und damit die Verbindung basierend auf dem Zielsystem klassifizieren.

Dann könnte sich das Bild etwas anders darstellen. Es ist nicht mehr "Internet" sondern natürlich nicht intern aber eben auch nicht extern sondern einfach ein anderes Rechenzentrum, welches für die Clients erreichbar ist.

Ehe sie mich jetzt steinigen möchte ich die Aussagekraft etwas relativieren. Ich weiß natürlich, dass die Server in der Cloud, abgesehen von VMs in Azure, nicht meine "eigenen" Server sind und Microsoft hier ein "Shared Hosting" betreibt. Theoretisch könnten z.B.: andere Tenants z.B. einen Exchange Send Connector einrichten, der Mails direkt zu meinem lokalen Exchange Hybrid Server sendet. Aber das lässt sich durch Zertifikate und Kontrolle der SMTP-Header recht einfach absichern. Es geht ja nicht darum komplett auf Application Layer Gateways zu verzichten.

Aber manchmal sind einfachere und damit vielleicht sogar sicherere Ansätze ein Teil der Lösung. Für die Nutzung von Cloud-Diensten gibt es eigentlich nur zwei nennenswerte Protokolle. Die Frage lautet als immer noch:

Zu welcher "Zone" gehört in dem Umfeld ein Office365/Microsoft 365 Backend, wenn ich die Server nicht selbst betreibe, sondern diese in einem anderen RZ stehen und als "Managed Service" betrieben werden? Ist das dann noch "Internet", wenn ich zwar auf dem Weg dorthin über das Internet gehe aber nicht abbiegen?

Diese Frage müssen Sie aber für sich beantworten und ich bin sicher, dass es sehr viele unterschiedliche Meinungen hier gibt.

Genaugenommen müssen Sie die Frage der "Sicherheit einer Cloud" aber schon viel früher beantwortet haben. Idealerweise schon ehe sie überhaupt den Vertrag mit Microsoft, Google, Amazon o.ä. unterschrieben haben. Denn die Daten und Metadaten sind eigentlich die kritischen Bausteine und weniger die Übertragungswege, die sich zudem recht gut abschotten lassen.

Die älteren Leser erinnern sich vielleicht an den Transitverkehr zwischen BRD und West-Berlin

HTTPS

Die meisten Dienste der Cloud nutzen mittlerweile das Protokoll HTTPS. Es ist aus meiner Sicht schon das "universeller Firewall Tunnelprotokoll", wenn ein Application Layer Gateway hier nicht reinschaut und das verwendete Protokoll versteht. Die Hersteller entsprechender Lösungen geben sich natürlich ganz viel Mühe auch MAPI, OneDrive u.a. zu verstehen. Aber letztlich sind Sie immer einen Schritt zurück, denn es gibt unzählige Cloud-Dienste und jeder Entwickler kann sein eigenes Protokoll auf Basis von HTTPS, REST, WebServices, WebSockets etc. entwickeln.

Daher ist es auch so wichtig, dass der Schutz auf dem Übertragungsweg nur ein Teil des Gesamtkonzepts ist. Sobald z.B. Dokumente per Rights-Management geschützt werden, wird auch ein Deep Inspection SSL-aufbrechender HTTP-Proxy an seine Grenzen kommen.

Das Application Layer Gateway kann dann nur noch die Zertifikate und URLs prüfen aber bei der Payload wird sie so oder so darauf vertrauen müssen, dass der Anwender keinen Unfug treibt und die Sicherheitseinstellungen in der Cloud (Stichwort Sharing mit anderen Tenants) und auf dem lokalen PC (Stichwort Endpoint Security) korrekt gesetzt sind

Teams RTP

Ganz anders sieht es aber bei der zweiten großen Workload in der Cloud aus. Microsoft Teams, Zoom Meetings, Google Meet und all die anderen Konferenzdienste, die durch COVID19 einen Boom erlebt haben, nutzen HTTPS nur im Notfall zur Übertragung von Audio, Video, Präsentationen und Bildschirmen. All diese Datensind "flüchtig" und zeitkritisch. Es werden sehr viele und bei Sprache eher kleine Pakete übertragen, die bei einem Verlust oder einer Verspätung bitte nicht erneut übertragen werden müssen und vor allem die Wiedergabe der nachfolgenden Pakete nicht ausbremsen dürfen.

Daher kommt hier UDP als Transport-Protokoll zum Einsatz über welches die Daten bei Teams per verschlüsseltem SRTP übertragen werden. Zu Zeiten von Skype for Business konnten Sie in der DMZ noch einen Edge-Server installieren, der als TURN-System die internen und externen Teilnehmer zueinander gebracht hat. Der TURN-Server ist aber eher ein Application Proxy, denn er inspiziert nicht den Inhalt der übertragenen Pakete, sondern setzt nur aktiv um. Eine solche Funktion gibt es aber mit Microsoft Teams nicht mehr zum "Selbst-Hosting". Die erforderlichen Transport Relay-Dienste von Microsoft Teams, Zoom, Google und Co stehen ebenfalls in der Cloud.

Die Clients bauen eine ausgehende verschlüsselte Verbindung zu dieser Gegenstelle auf, um über dieses Relay dann mit anderen Clients zu kommunizieren. Ein Paketfilter kann natürlich auf die bekannten Gegenstellen filtern, so dass ein Missbrauch dieser Ports und Protokolle zu anderen Servern unterbunden wird. Als Firma vertrauen Sie aber darauf, dass der Cloud-Anbieter eine sichere Authentifizierung der Clients erzwingt, so wie sie dies mit einem eigenen Application Layer Gateway vermutlich auch machen würden.

Eine bessere Firewall kann auch noch den TURN-Handshake analysieren und so die etablierte Verbindungen erkennen:

Die eigentliche Nutzdaten werden in einem RTP-Frame eingepackt, welcher wiederum durch den UDP-Header und IP-Header eingeschlossen wird.

Eine Firewall muss also nur erkennen, dass der verwendete Port ein RTP-Paket und kann zumindest den Codec (Hier 108) erkennen.

Sie könnte sogar noch die Sequence-Nummer und dem Time-Marker prüfen und die Anzahl der Pakete und deren Größe ermitteln und damit auf die Bandbreite, Audio belegt ca. 100kBit, schließen. Das könnte alles die Sicherheit erhöhen aber eine Garantie wäre es nicht, dass nicht jemand per "Daten als Töne über VoIP", quasi ein Soft-Modem diesen Kanal für unerlaubte Datenübertragungen nutzt.

Denn "Reinhören" kann hier keine noch so gute Firewall. Sie müsste dazu den Handshake per HTTPS decodieren, die Kandidaten und Crypto-Keys ermitteln und als als "Man in the Middle" einschleifen. Ich kenne aktuell kein Produkt, welches so eine Funktion bereitstellt.

Achtung: Verwechsel sie nicht ein ALG für SIP mit dem RTP-Protokoll. Es gibt von VoIP-Anbietern durchaus Software zur Absicherung von SIP-Vermittlungsstellen. Skype for Business hat auch einen entsprechenden Edge Server.

Mögliche Topologie

Wenn ich all die Aussagen nun zusammennehme, d.h. dass HTTPS geht über einen Proxy gehen kann aber SRTP-Verkehr irgendwie direkt zum Cloud-Service gehen muss, dann könnte folgende Topologie vielleicht ein Kompromiss sein. Denn letztlich geht es um Kompromisse und Abwägen von Sicherheitsrisiken. Wenn ein Statement wie "Alles muss über ein Application Layer Gateway gehen" unverrückbar im Raum stehen, dann dürfen Sie weder Teams noch Google noch Zoom machen, denn alle basieren auf UDP, was nicht nur technisch sinnvoll ist, sondern von den Anbietern auch gefordert wird. Hier am Beispiel Microsoft Teams:

“The four UDP ports are used for media such as audio and video, to ensure they flow correctly.
Opening these ports is essential for a reliable Teams deployment. Blocking these ports is unsupported and will have an effect on media quality.”
https://docs.microsoft.com/en-us/microsoftteams/3-envision-evaluate-my-environment#firewall-and-proxy-requirements 

Der Weg über HTTPS ist zwar möglich aber sie gewinnen nicht mehr an Sicherheit aber viel mehr Traffic und Last auf ihren Servern und negative Effekte bei der Funktion. Selbst ein "SelfHosting" von z.B. Jitsi, Big Blue Button oder einer anderen Lösung verlagert nur die Frage der "Datenhaltung" aber auch hier kommt UDP mit SRTP zum Einsatz. Es ist eher eine Frage, was ein legitimes "Application Layer Gateway" für SRTP ist. Wie stellt sich dieses Bild für sie dar?

Neben wir an, dass die internen Clients bislang aus Gründen der Sicherheit weder einen Leitweg zum Internet noch eine Namensauflösung hätten. Dann wären folgende Änderungen erforderlich: (von links nach rechts)

  • Client: Leitweg zu den Office 365 Transport Relays
    Dazu sind die routen zu den drei veröffentlichten Subnetzen (Stand 2021) einzurichten, damit diese zur internen Firewall kommen. Über Teams rate ich noch dazu, die Source-Ports der Clients festzulegen, z.B. Audio =50000-50019, Video =50020-50039 etc.
  • Namensauflösung
    Sie müssen natürlich dann noch sicherstellen, dass die Client auch die Namen der Cloud-Server auflösen können, z.B. indem Sie einen selektiven Forwarder für teams.microsoft.com und andere Hosts einrichten.
  • Interner Paketfilter/Firewall
    Diese interne Firewall muss Zugriffe von Clients und den konfigurierten Quellports zu den drei Subnetzen und den bekannten Port 3478-3481 über das Protokoll UDP erlauben. Sofern die Firewall auch RTP erkennen und bewerten kann, können Sie diese Funktion als zusätzlichen Schutz nutzen. Sie muss dann die Pakete zu einem System senden, welches UDP verarbeiten kann. Das ist meist nicht der HTTP-Proxy, der parallel für die Signalisierung u.a. schon vorhanden ist.
  • NAT als "Application Layer Gateway"
    Eigentlich ist es nur ein NAT-Router, denn was in SRTP drin ist, kann das System nicht verstehen. Es kann aber die Pakete per NAT so Richtung Internet weitergeben, dass diese zum Transportrelay in der Cloud kommen können. Auch dieses System kann die Quell- und Zielports prüfen und RTP zumindest oberflächlich analysieren und vor allem die Sequencenummer verfolgen.
    Theoretisch könnte es sogar eine Kopplung zum HTTPS-Proxy oder AzureAD geben. Wenn Sie so erfahren könnten, dass ein Anwender aktiv in Teams angemeldet ist, könnten Sie dann erst dessen Client-IP zulassen und die RTP-Verbindung besser protokollieren. Mit etwas Phantasie könnte man diesen zugestopften NAT-Proxy vielleicht als Application Layer Gateway bezeichnen.
  • Externer Paketfilter/Firewall
    Dieses System unterbindet jeden versuchten Verbindungsaufbau von externen Adressen auf den RTP-NAT-Proxy. Das System erlaubt nur ausgehende Verbindungen zu den bekannten Office 365 IP-Adressen mit den Quell- und Ziel-Ports und die Rückantworten auf bestehende Verbindungen. Ein Angreifer müsste schon einen offenen Quell-Port und die passende IP-Adresse bei Microsoft und die Sequencenummer erraten und ein störendes Paket per Spoofing einliefern.

Selbst wenn das Paket wirklich bis zum Client kommt, wird es es verwerfen, da er es nicht entschlüsseln kann. Ich denke das Risiko ist sehr gering und da hätte ich mehr Sorge vor einer DDoS-Attacke auf ihre Bandbreite.

Wenn Sie aber schon für Teams eine Überholspur einrichten, dann sollten Sie sich auch mit der Fragestellung beschäftigen, ob auch andere Dienste durch so eine Abkürzung nicht nur schnelle für die Anwender sind, sondern auch Last von ihren HTTPS-Proxy-Systemen nehmen.

ALG für Teams Transport Relay

Ich habe bei einem Kunden sogar schon einmal Überlegungen angestellt, ob wir nicht On-Premises ein System aufstellen können, welches auf Port 3478-3481 auf eingehende Verbindungen von internen Clients wartet. Die Clients könnten dann per DNS auf diese Server verwiesen werden, die dann zu jeder Verbindung ihrerseits eine Verbindung zu den Cloud-Services aufbauen.

Es sieht im Prinzip aus wie ein Loadbalancer der einfach nur umgedreht konfiguriert wird, d.h. die Clients und die Virtual-IP sind noch intern aber die "Reals Server" stehen dann einfach in der Cloud.

  • Real-Server Liste
    Das System müsste schon selbst die Unzahl der Transport Relay-Server in der Cloud als "Backend" finden, z.B. per DNS-Anfrage. Es dürfte zum Scheitern verurteilt sein, wenn wir die Server manuell pflegen wollten
  • Fehlende Inspektion
    Ein ALG soll als primäres Ziel ja das Protokoll verstehen und umsetzen. Bei ICE/TURN gibt es aber nicht viel zu verstehen oder zu schützen. Der Client bekommt per Signalisierung über HTTPS seine temporären Zugangsdaten, über die er sich per TURN dann Kandidaten holt.
  • Kein MITM
    Da die Verschlüsselung immer zwischen den RTP-Endpunkten erfolgt, kann so ein System auch nicht in die Payload schauen. Es müsste sich schon in die Signalisierung einschieben und dort die Aushandlung der RTP-Verbindung modifizieren.

Was auf den ersten Blick interessant erscheint, hat aber keinen wirklichen Nutzen. Daher haben wir diese Überlegungen nicht weiter geführt.

Einschätzung

Ich bin weder Prüfer noch verantwortlicher Planer solcher hochsicheren Strukturen. Aber mein technischer Rat wird schon eingeholt, um verschiedene Sachverhalte zu erklären und Möglichkeiten und Grenzen aufzuzeigen.

Wenn Sie vor solchen Herausforderungen stehen und die Ausführungen auf der Seite nicht ausreichend sind, dann können Sie meine Kollegen und mich gerne ansprechen.

Ich bin überzeugt, dass ein Konferenz-Dienst in der Cloud für viele Firmen die beste Plattform ist, insbesondere wenn die Teilnehmer verteilt an vielen Standorten mit eigenem Internet-Ausgang arbeiten und die eigenen WAN-Verbindungen knapp sind. Einige technische Details dazu finden Sie auf Kein Teams für Schulen? und anderen Seiten.

Aber Sicherheit für die eigenen Clients, Server und Netzwerk ist wichtig aber muss mit der Nutzung von Cloud-Diensten neu gedacht werden. Wer keine eigene Leitung zu Microsoft, Google und Co wirft oder ein VPN aufbaut, wird einen Teil seiner Daten auch über Teilstecken übertragen, die auch vom Internet genutzt werden. Auch wenn die Daten selbst alle per TLS verschlüsselt sind, sind die Übergänge entsprechend zu bewerten. Die große Frage zur Sicherheit des Cloud-Service selbst hinsichtlich Verfügbarkeit, Datenschutz etc. würde die Seite endlos werden lassen.

Ich lese die Dokumente die mir vorliegen aber so, dass auch Portfilter und NAT für Teams "gehen" sollten. Aber das kommt mir vor wie der Versuch einer Einzelabnahme beim TÜV zur Eintragung der Ochsenblinker am Motorradlenkrad, während sich die Automobilfirmen im Design ihrer Leuchtkörper samt Animation einen Wettbewerb liefern.

"Die Fahrtrichtungsanzeiger müssen nach dem Einschalten mit einer Frequenz von 1,5 Hz ± 0,5 Hz (90 Impulse ± 30 Impulse in der Minute) zwischen hell und dunkel ... blinken "
§ 54 StVZO Straßenverkehrs-Zulassungs-Ordnung (StVZO) § 54 Fahrtrichtungsanzeiger
https://www.gesetze-im-internet.de/stvzo_2012/__54.html

Schon interessant, dass ein Lauflicht/Lichtorgel" als "Blinken" durchgeht und dabei teilweise das Tagfahrlicht noch abgedimmt wird.

Am besten suchen Sie den Kontakt zu der Firma, die ihre Planung letztlich prüft und zertifiziert. Leider gibt es anscheinend auch hier immer noch Firmen oder Personen, die eine BSI/KRITIS/ISO-Prüfung verkaufen aber Sie ansonsten mit ihren Fragezeichen alleine lassen. Bei Fahrzeugen gibt es ja auch mindestens vier Institutionen (TÜV, Dekra, GTÜ oder KÜS) zwischen denen sie wählen können.

Weitere Links