Sophos Firewall Application Control einrichten und testen
Application Control auf Sophos Firewall erkennt Anwendungen unabhängig vom reinen Port. Damit lassen sich zum Beispiel Remote-Control-Tools, Tunneling-Anwendungen, Streaming, Cloud Storage, Messenger oder riskante Browser-Umgehungen gezielt erlauben, blockieren oder protokollieren.
Der praktische Nutzen entsteht aber erst, wenn Application Control in der richtigen Firewall-Regel aktiv ist, die Anwendung wirklich erkannt wird und Logs ausgewertet werden. Eine gespeicherte Application Filter Policy allein blockiert noch nichts.
Kurzantwort
Application Control wird in zwei Schritten genutzt:
- Unter Applications > Application filter eine Application Filter Policy planen oder erstellen.
- In der passenden Firewall-Regel unter Other security features bei Identify and control applications (App control) auswählen.
Danach muss man mit einem echten Testclient prüfen, ob der Traffic über diese Regel läuft und ob die Anwendung im Log Viewer korrekt erkannt wird. Bei verschlüsseltem Traffic kann TLS Inspection entscheidend sein, weil die Firewall sonst je nach Anwendung weniger Details sieht.
Wann Application Control sinnvoll ist
Application Control ist vor allem dann nützlich, wenn Ports allein nicht genug Aussagekraft haben. Viele Anwendungen verwenden HTTPS, wechselnde Ziele oder Cloud-Infrastruktur. Eine reine Portregel sieht dann nur 443, aber nicht, ob dahinter ein erlaubter Geschäftsdienst, ein Remote-Control-Tool oder ein unerwünschter Cloud-Speicher steckt.
Typische Einsatzfälle:
- TeamViewer, AnyDesk, Tor oder Proxy-Tools blockieren
- Streaming oder Social Media in bestimmten Netzen einschränken
- Cloud Storage kontrollieren
- Messenger oder Spiele in Gäste- oder Schulnetzen begrenzen
- Anwendungserkennung für Reporting und Analyse aktivieren
- Traffic Shaping für erkannte Anwendungen vorbereiten
Wenn es nicht um Erkennung oder Blockierung, sondern um Priorisierung oder Bandbreitenbegrenzung geht, passt zusätzlich Application Traffic Shaping auf Sophos Firewall konfigurieren.
Voraussetzungen
Vor der Konfiguration sollten diese Punkte geprüft werden:
- passende Lizenz mit Web Protection beziehungsweise Application Control
- betroffene Firewall-Regel ist bekannt
- Log firewall traffic ist für die Testregel aktiv
- gewünschte Anwendung oder Kategorie ist fachlich klar
- Testclient und Testziel sind definiert
- bei HTTPS-Anwendungen ist klar, ob TLS Inspection eingesetzt werden soll
- Application-Signaturen und Pattern-Updates funktionieren
Den Lizenzstatus prüft man unter System > Administration > Licensing. In typischen Sophos-Firewall-Bundles mit Web Protection ist Application Control enthalten. Die konkrete Lizenzlogik sollte trotzdem vor produktiver Einführung kontrolliert werden, besonders bei abgelaufenen Subscriptions oder Testlizenzen.
Application Filter planen
Ein guter Application Filter ist nicht einfach eine lange Blockliste. Zuerst sollte klar sein, was erreicht werden soll.
- Riskante Remote-Control-Tools blockieren: gezielte Anwendungen oder Kategorie blockieren.
- Gäste-WLAN einschränken: unerwünschte Kategorien blockieren und erlaubte Basisdienste offen lassen.
- Anwendung nur protokollieren: zunächst
Allowmit Logging und Reports verwenden. - False Positive vermeiden: engere Anwendungsauswahl statt breite Kategorie nutzen.
- Geschäftskritische Anwendung priorisieren: Application Control mit Traffic Shaping kombinieren.
Für produktive Netze ist ein Beobachtungsmodus oft sinnvoll: Zuerst Application Control aktivieren, Logs und Reports prüfen, danach gezielt blockieren. So sieht man, welche Anwendungen wirklich vorkommen und ob ein Block legitime Prozesse stören würde.
Bei breiten Kriterien sollte man die spätere Pflege mitdenken. Neue Anwendungen werden durch Updates der Application-Signaturdatenbank automatisch in Application Filter Policies und Firewall-Regeln berücksichtigt. Wenn eine Regel zum Beispiel alle High-Risk-Anwendungen blockiert, kann eine neue High-Risk-Signatur später ohne weitere manuelle Policy-Änderung blockiert werden. Das ist gewünscht, muss aber im Change- und Review-Prozess bekannt sein.
Rollout in Phasen planen
Application Control sollte nicht in einem grossen Schritt für alle Netze scharf geschaltet werden. Besser ist ein kleiner Rollout mit klarer Testgruppe, sichtbarem Logging und einem definierten Entscheid, wann aus Beobachtung eine Blockierung wird.
Ein praktikabler Ablauf:
- Inventar: Herausfinden, welche Anwendungen tatsächlich vorkommen. Dafür Application Filter mit Logging verwenden, noch ohne breite Blockierung.
- Pilot: Ausgewählte Benutzer oder ein Testnetz prüfen. Einzelne riskante Anwendungen blockieren und Rule ID sowie Logs eng kontrollieren.
- Produktivsetzung: Bestätigte Policy auf Zielnetz anwenden. Filter in produktiver Regel aktivieren und Ausnahmen dokumentieren.
- Betrieb: Wirkung und Nebenwirkungen überwachen. Reports, Log Viewer, Central Reporting oder Syslog regelmässig prüfen.
Vor der Produktivsetzung sollte klar sein, welche Anwendungen erlaubt bleiben müssen. Dazu gehören oft Update-Dienste, Remote-Support, Collaboration-Tools, Cloud-Speicher, Telefonie oder branchenspezifische Anwendungen. Wenn diese Abhängigkeiten erst nach dem Block sichtbar werden, wirkt Application Control schnell wie ein Störfaktor statt wie eine Schutzfunktion.
Für die Abnahme lohnt sich eine kurze Entscheidungsliste: Welche Anwendung wird blockiert, welche Benutzergruppe ist betroffen, welche Ausnahme ist erlaubt, wer ist fachlicher Owner und wann wird die Policy wieder geprüft? Diese Dokumentation ist wichtiger als ein perfekter erster Filter.
Application Filter, Application Object und Shaping unterscheiden
Die Begriffe liegen nah beieinander, lösen aber unterschiedliche Aufgaben. Diese Trennung spart viel Fehlersuche:
- Application Filter: legt fest, welche Anwendungen erlaubt, blockiert oder protokolliert werden. Typisch für Remote-Control-Tools, Cloud-Speicher oder einen Beobachtungsmodus.
- Application Object: fasst Anwendungen als Objekt zusammen. Sinnvoll für wiederverwendbare Gruppen, wenn dieselbe Auswahl mehrfach gebraucht wird.
- Application-based Traffic Shaping: priorisiert oder begrenzt erkannte Anwendungen. Typisch für Teams-Priorisierung, Streaming-Begrenzung oder Gäste-WLAN-Drosselung.
- Synchronized Application Control: ergänzt die Anwendungserkennung mit Daten von Sophos-Endpoint-Systemen über Security Heartbeat. Das hilft besonders bei Programmen, die die Firewall sonst nur generisch oder gar nicht erkennt.
Für eine reine Block- oder Allow-Policy ist der Application Filter der wichtigste Einstieg. Application Objects und Traffic Shaping werden erst interessant, wenn die Anwendungsauswahl wiederverwendet oder Bandbreite gezielt gesteuert werden soll.
Synchronized Application Control ist kein Ersatz für saubere Firewall-Regeln. Es braucht Sophos Central, Security Heartbeat und passende Sophos-Endpoint-Abdeckung. Neu erkannte Anwendungen erscheinen in eigenen Kategorien wie SyncAppCtl discovered und sollten nicht blind blockiert werden. Erst prüfen, dann kategorisieren, danach in Application Filter aufnehmen.
Erkannte Anwendungen erhalten dabei automatisch ein Status-Label: New für noch unbekannte Anwendungen, Mapped für automatisch einer Kategorie zugeordnete Anwendungen und Customized für manuell angepasste Einträge. Sophos unterstützt Synchronized Application Control für bis zu 15.000 Anwendungen und speichert pro Anwendung und Endpoint nur die letzten fünf Vorkommen, um Speicherplatz zu sparen. Diese Grenze ist besonders relevant, wenn man forensisch nachvollziehen will, wie oft eine Anwendung auf einem Endpoint aufgetreten ist.
Application Filter erstellen
Menüpfad:
Applications > Application filter
In älteren Navigationsansichten kann der Pfad als Protect > Applications > Application filter erscheinen.
Vorgehen:
- Add öffnen.
- Einen sprechenden Namen vergeben, zum Beispiel
Block_Remote_Control_Tools. - Eine bestehende Policy als Template wählen, zum Beispiel eine Allow-All-Policy als Ausgangspunkt für gezielte Blockregeln.
- Policy speichern.
- Policy erneut öffnen und eine Regel innerhalb des Filters hinzufügen.
- Anwendung, Kategorie, Risiko, Characteristics, Technology, Classification oder Smart Filter auswählen.
- Aktion setzen, zum Beispiel
DenyoderAllow. - Schedule setzen, falls die Regel nur zeitweise gelten soll.
- Regel speichern und anschliessend die Policy speichern.
Bei Kategorien sollte man vorsichtig sein. Eine breite Kategorie kann mehr Anwendungen treffen als erwartet. Für erste Tests sind einzelne Anwendungen oder klar umrissene Gruppen oft besser als ein grosser Sammelblock.
Beim Hinzufügen einer Regel gibt es zwei typische Arbeitsweisen. Select All mit Filtern ist passend, wenn eine ganze Gruppe gemeint ist, zum Beispiel Kategorie File Transfer, Characteristics Transfer files und Technology Browser Based. Select Individual Application ist besser, wenn nur einzelne Anwendungen wie AnyDesk, TeamViewer oder ein bestimmter Cloud-Dienst betroffen sein sollen. Der Smart Filter sucht nach Name und Beschreibung einer Anwendung; er ersetzt keine fachliche Prüfung der Trefferliste.
Der Filter Classification gilt nur für Cloud-Anwendungen. Wenn eine Cloud-App später neu klassifiziert wird, aktualisiert Sophos Firewall auch Regeln, die auf dieser Classification basieren. Solche Regeln sind praktisch, aber dynamischer als eine feste Liste einzelner Anwendungen.
Beispiel: Browserbasierte File-Transfers blockieren
Ein gutes erstes Beispiel ist das Blockieren browserbasierter Dateiübertragungen in einem Gäste- oder Clientnetz. Dabei wird nicht pauschal die ganze Kategorie File Transfer blockiert, sondern die Auswahl auf browserbasierte Dateiübertragungen eingegrenzt.
Konfiguration im Application Filter:
- Applications > Application filter öffnen.
- Policy erstellen, zum Beispiel
Block_File_Transfer. - Als Template eine passende Allow-Policy wählen.
- Policy speichern und erneut öffnen.
- Add für eine neue Filterregel öffnen.
- Select All verwenden und die Auswahl mit Category: File Transfer, Characteristics: Transfer files und Technology: Browser Based eingrenzen.
- Action auf
Denysetzen. - Schedule auf
All the timesetzen, sofern keine Zeitsteuerung gewünscht ist. - Filterregel speichern und danach die Policy speichern.
Dieses Beispiel ist bewusst enger als ein pauschaler Block aller File-Transfer-Anwendungen. In vielen Firmen wären sonst legitime Cloud-, Update-, Backup- oder Collaboration-Dienste betroffen. Vor produktiver Nutzung sollte der Filter im Log Viewer mit realen Clients getestet werden.
In Firewall-Regel aktivieren
Application Control wirkt erst, wenn der Filter in einer Firewall-Regel ausgewählt ist.
Menüpfad:
Protect > Rules and policies > Firewall rules
Vorgehen:
- Die Firewall-Regel öffnen, über die der betroffene Traffic wirklich läuft.
- Den Abschnitt Other security features öffnen.
- Bei Identify and control applications (App control) den Application Filter auswählen.
- Log firewall traffic aktivieren, mindestens für Test und Abnahme.
- Regel speichern.
- Mit einem definierten Client testen.
Die Regelreihenfolge ist entscheidend. Wenn der Traffic bereits von einer allgemeineren Regel weiter oben verarbeitet wird, erreicht er die Regel mit Application Control nicht. Dann sieht die Konfiguration im WebAdmin korrekt aus, hat aber keine Wirkung.
Wenn eine neue LAN-WAN-Regel erstellt wird, muss NAT separat bedacht werden. Sophos-Beispiele nutzen oft Create linked NAT rule mit MASQ für einfachen Internetzugang. Bei bestehenden produktiven Regeln sollte man aber nicht unbedacht neue NAT-Regeln erzeugen, sondern prüfen, welche SNAT/MASQ-Regel bereits für diesen Traffic gilt.
Für benutzer- oder gruppenbasierte Application-Control-Policies muss die Firewall-Regel den Benutzerkontext wirklich matchen. Match known users und funktionierende Authentifizierung sind dann genauso wichtig wie der Application Filter selbst. Ohne Benutzerkontext greift die Policy nur auf Netz-, Zonen- und Service-Kriterien.
Bei neuen Regeln sollte man ausserdem bewusst zwischen IPv4 und IPv6 wählen. Application Control wird in der jeweiligen Firewall-Regel aktiviert. Wenn ein Client über IPv6 einen anderen Pfad nimmt als über IPv4, sieht der Test sonst sauber aus, obwohl ein Teil des Traffics an der erwarteten Regel vorbeiläuft.
Die Grundlagen zu Source, Destination, Services, Security Features und Regelreihenfolge stehen in Sophos Firewall-Regeln verstehen und sicher konfigurieren.
Regelabgleich bewusst prüfen
Vor dem Speichern sollte die Regel wie ein Testfall gelesen werden:
- Source zone und Source network: Der Testclient muss wirklich über diese Zone und dieses Netz kommen.
- Destination zone und Destination network: Breite Ziele können funktionieren, sind aber schlechter nachvollziehbar.
- Services: Bei Webtraffic ist oft TCP
80/443relevant; QUIC läuft über UDP443. - Web policy, IPS und TLS Inspection: Mehrere Security Features können denselben Flow beeinflussen.
- Log firewall traffic: Ohne Logging wird die Wirkung im Log Viewer schwer beweisbar.
Wenn Application Control neu eingeführt wird, sollte die erste Regel lieber etwas enger und gut messbar sein. Eine riesige LAN-zu-WAN-Regel mit vielen Ausnahmen ist für die Abnahme deutlich mühsamer.
TLS Inspection und Erkennung
Application Control kann auch ohne vollständige TLS Inspection bestimmte Anwendungen erkennen. Bei vielen modernen HTTPS- und Cloud-Diensten sieht die Firewall ohne Entschlüsselung aber nur eingeschränkte Informationen wie IP-Adresse, SNI, Zertifikatsdaten, Hostname oder Verbindungsmetadaten.
Das reicht nicht in jedem Fall für zuverlässige Erkennung. Wenn eine Anwendung über HTTPS nicht wie erwartet erkannt wird, sollte man prüfen:
- läuft der Traffic über die richtige Firewall-Regel?
- ist Application Control in dieser Regel aktiv?
- wird die Anwendung grundsätzlich von Sophos erkannt?
- ist TLS Inspection für diesen Traffic nötig und vertretbar?
- gibt es QUIC oder HTTP/3, das die Kontrolle erschwert?
- greifen Web Policy, IPS oder DNS Protection zusätzlich?
TLS Inspection sollte schrittweise und mit Ausnahmen eingeführt werden. Der passende Ablauf steht in Sophos Firewall TLS Inspection richtig einführen. Für QUIC und HTTP/3 passt Sophos Firewall QUIC und HTTP/3 richtig blockieren.
Bei Cloud-Anwendungen ist der Unterschied besonders sichtbar: Grundlegende Bytes- und Nutzungsdaten brauchen vor allem aktiviertes Firewall-Logging. Genauere Upload-/Download- und Dateityp-Informationen sieht man aber nur zuverlässig, wenn HTTPS entschlüsselt wird. Manche Anwendungen übertragen Dateien über eigene Mechanismen; dann können Detailfelder leer bleiben oder unvollständig wirken, obwohl Traffic vorhanden ist.
Für Cloud-App-Reporting empfiehlt sich deshalb ein Dreiklang: Log firewall traffic aktivieren, HTTPS dort entschlüsseln, wo es organisatorisch und technisch vertretbar ist, und eine Web Policy verwenden, die nicht einfach None ist. Das macht Application-Control-Daten im Betrieb deutlich brauchbarer.
Wirkung testen
Nach dem Aktivieren sollte man nicht nur auf Benutzerfeedback warten. Ein sauberer Test spart viel Zeit.
Praktischer Ablauf:
- Testclient und Quell-IP festlegen.
- Anwendung bewusst starten oder Ziel aufrufen.
- Im Log viewer nach Source-IP, Destination, Service und Anwendung filtern.
- Prüfen, welche Firewall Rule ID getroffen wurde.
- Prüfen, ob Application Control die Anwendung erkennt.
- Application ID, Kategorie, Aktion und Application Filter notieren.
- Bei Block prüfen, ob der Block fachlich gewollt ist.
- Bei unklarer Erkennung Packet Capture, Service-Logs und bei zentralem Logging die Syslog-Felder ergänzen.
Application-Control-Events erscheinen im Log Viewer als Application- beziehungsweise Content-Filtering-Ereignisse. Für die Abnahme sind vor allem Firewall Rule ID, Benutzer, Anwendung, Kategorie, Risiko, Aktion, Quelle und Ziel relevant. Bei Syslog- oder SIEM-Auswertung sollten zusätzlich Felder wie fw_rule_id, application_name, application_filter_policy, application_category, application_risk, status und appresolvedby geprüft werden. Letzteres hilft einzuordnen, ob die Anwendung etwa über Signatur, Proxy-Logik oder Synchronized Application Control erkannt wurde.
Application Control verwendet im technischen Pfad häufig ips.log. Die Logzuordnung steht in Sophos Firewall Troubleshooting: Services und Logs. Für die Abgrenzung mit Log Viewer und Packet Capture hilft Sophos Firewall Regel testen mit Log Viewer, Policy Test und Packet Capture.
Vom Beobachten zum Blockieren wechseln
Der Wechsel von reiner Erkennung zu Blockierung sollte bewusst erfolgen. In vielen Umgebungen ist es besser, Application Control zuerst als Beobachtungs- und Reporting-Werkzeug zu nutzen. Danach werden nur Anwendungen blockiert, deren Risiko, Benutzerkreis und geschäftliche Abhängigkeit verstanden sind.
Vor einer Blockierung sollte man prüfen:
- Welche Benutzer, Netze oder Geräte verwenden die Anwendung wirklich?
- Welche Firewall-Regel und Rule ID sieht man im Log Viewer?
- Wird die Anwendung zuverlässig erkannt oder nur als generische Kategorie?
- Gibt es legitime Business-Nutzung, Supportfälle oder Hersteller-Tools?
- Soll die Anwendung überall blockiert werden oder nur in Gast-, Schul-, Client- oder Servernetzen?
- Wer genehmigt eine Ausnahme und wann wird sie wieder geprüft?
Praktisch sauber ist ein kurzer Ablauf: erst Logdaten sammeln, dann einzelne Anwendung oder kleine Gruppe blockieren, danach mit Testclient und Log Viewer validieren. Wenn ein Block zu breit wirkt, sollte man nicht den ganzen Application Filter deaktivieren, sondern die betroffene Anwendung, Kategorie oder Regelposition gezielt anpassen.
Wenn Application Control nicht greift
Bei Problemen sollte nicht sofort der ganze Filter deaktiviert werden. Zuerst prüfen, an welcher Stelle der Ablauf bricht.
- Kein Logeintrag zur Testverbindung: Logging fehlt oder Traffic erreicht die Firewall-Regel nicht. Rule ID, Quellzone und Packet Capture prüfen.
- Log Viewer zeigt andere Rule ID: Eine allgemeinere Regel steht weiter oben. Regelreihenfolge und Match-Kriterien korrigieren.
- Anwendung bleibt
unknownoder generisch: Die Erkennung reicht ohne mehr Kontext nicht aus. TLS Inspection, QUIC und Application-Signaturen prüfen. - Block trifft zu viele Dienste: Kategorie oder Smart Filter ist zu breit. Einzelne Anwendungen oder kleinere Gruppen verwenden.
- Nach Pattern-Update wird plötzlich mehr blockiert: Eine breite Regel auf Risk, Category oder Classification trifft neue Signaturen. Regelkriterien und Change-Prozess prüfen.
- Cloud-App-Details fehlen: Ohne HTTPS-Decryption oder ohne Web Policy sind Upload-, Download- und Dateitypdetails begrenzt. Cloud-App-Reporting und TLS-Status prüfen.
- Block wirkt nur bei manchen Clients: Unterschiedliche Regel, Zone, Benutzergruppe oder Browserpfad prüfen. Testclient, Benutzer und Netzwerkpfad vergleichen.
- IPv6 verhält sich anders als IPv4: Separate IPv6-Regel, anderer DNS-Pfad oder anderer Browserpfad möglich. Beide Protokolle bewusst testen oder IPv6 im Regelwerk sauber berücksichtigen.
Der wichtigste Prüfpunkt ist die Rule ID. Wenn die erwartete Regel nicht getroffen wird, ist die Application-Control-Policy fast nie die eigentliche Ursache.
False Positives sauber behandeln
Wenn Application Control legitimen Traffic blockiert, sollte man nicht sofort den ganzen Filter deaktivieren.
Sinnvolle Reihenfolge:
- Betroffene Anwendung und Logeintrag dokumentieren.
- Prüfen, welche Firewall-Regel und welcher Application Filter beteiligt sind.
- Anwendung, Kategorie und Aktion im Filter prüfen.
- Prüfen, ob die Anwendung durch TLS Inspection anders erkannt wird.
- Ausnahme möglichst eng setzen: Anwendung, Quellnetz, Benutzergruppe oder Ziel.
- Owner und Review-Datum für die Ausnahme dokumentieren.
Eine Ausnahme für Any oder eine breite Kategorie löst den aktuellen Fall oft schnell, schwächt aber die Kontrolle dauerhaft. Besser ist eine kleine, nachvollziehbare Ausnahme mit klarer Begründung.
Typische Fehler
- Application Filter erstellt, aber nicht in Regel ausgewählt: Keine Wirkung auf Traffic. Filter in der echten Firewall-Regel aktivieren.
- Traffic läuft über andere Regel: Der Filter wird nie erreicht. Rule ID im Log Viewer prüfen.
- Zu breite Kategorie blockiert: Legitime Cloud- oder Business-Dienste können betroffen sein. Einzelne Anwendungen oder engere Gruppen verwenden.
- Dynamische Filter nicht verstanden: Risk, Category oder Classification können durch Signatur- und Cloud-App-Updates neue Treffer bekommen. Regelmässig prüfen.
- HTTPS-Erkennung überschätzt: Anwendung wird nicht zuverlässig erkannt. TLS Inspection und QUIC-Verhalten prüfen.
- Logging fehlt: Wirkung bleibt unsichtbar. Regel-Logging für Test und Betrieb aktivieren.
- Ausnahme zu breit: Schutzfunktion wird praktisch ausgehebelt. Ausnahme eng und mit Review-Datum setzen.
Betriebscheck
Application Control sollte regelmässig geprüft werden. Anwendungen ändern sich, Cloud-Dienste nutzen neue Endpunkte, Benutzer verwenden neue Tools und Signaturen werden aktualisiert.
Dokumentieren sollte man:
- Zweck des Application Filters
- betroffene Firewall-Regeln
- blockierte oder erlaubte Anwendungen
- bekannte Ausnahmen
- fachlicher Owner
- Review-Datum
- letzte relevante Änderung
Wenn Application Control für kritische Business-Anwendungen, Schulnetze oder Compliance-Vorgaben eingesetzt wird, sollte zusätzlich Central Reporting, Syslog oder SIEM geprüft werden. Für zentrale Auswertung passt Central Firewall Reporting aktivieren oder Sophos Firewall Syslog und SIEM einrichten.
Checkliste
- Lizenzstatus geprüft.
- Betroffene Firewall-Regel eindeutig identifiziert.
- Application Filter mit klarem Zweck erstellt.
- Template, dynamische Filter und Regelkriterien dokumentiert.
- Filter in der richtigen Firewall-Regel ausgewählt.
- Regel-Logging aktiv.
- Testclient und Testanwendung definiert.
- Log Viewer auf Rule ID und Application Control geprüft.
- Vor Blockierung echte Nutzung, Owner und Ausnahmeregel geklärt.
- IPv4- und IPv6-Pfad geprüft, wenn beide im Netz aktiv sind.
- TLS Inspection und QUIC bewertet, wenn HTTPS-Erkennung unklar ist.
- Cloud-App-Reporting bei Bedarf mit HTTPS-Decryption und Web Policy geprüft.
- Ausnahmen eng dokumentiert.
- Review-Termin gesetzt.