Microsoft Teams mit BYOD nutzen und trotzdem einen ruhigen Schlaf haben!

In Zeiten der Pandemie und den damit verbundenen Herausforderungen „wie können meine Mitarbeiter von zu Hause aus arbeiten, ohne selber ein ‚company owned device‘ [aka Notebook/Laptop] gestellt zu bekommen“ stellt sich die Frage wie eine Arbeit von zu Hause compliant ablaufen kann.

Natürlich ist man schnell mit den Antworten:

  1. Jedem Mitarbeiter ein Gerät stellen [sowohl logistisch als auch monetär nicht sofort ‚mal eben‘ zu realisieren]
  2. Windows virtual Desktop – auch nicht in jeder Lebenslage und für jedes Arbeitsszenario das Optimum
  3. Einfach zulassen – „was könnte schlimmstenfalls schon passieren?“ [Bitte nicht! Dieser Punkt dient lediglich der Vollständigkeit!]
  4. Die Nutzung von Teams auf einem beliebigen Gerät zulassen, dabei aber ausreichend abgesichert um Datenabfluss (oder z.B. Ransomware) zu verhindern.

In diesem Post möchte ich euch Ideen für Punkt 4 geben – es hängt natürlich immer vom Einsatzzweck, den betroffenen Rollen, Inhalten, etc. ab, aber wer kann, der darf gerne meine Ideen nutzen:

  1. Idee
  2. Conditional Access konfigurieren
    1. BYOD Teams App verbieten
    2. BYOD Teams im Browser umleiten
  3. MCAS mit notwendigen Apps verbinden
  4. MCAS Session Policy konfigurieren
  5. User Experience
  6. Bonus: Copy, Paste & Print verhindern

Dreh und Angelpunkt für die Umsetzung von BYOD mit Teams ist die Nutzung von Conditional Access und Microsoft Cloud App Security Session Policies.

Wichtig: manche der hier gezeigten Technologien befinden sich zum Zeitpunkt der Erstellung dieses Posts im Status „Preview“ – die Nutzung erfolgt also auf eigene Gefahr und immer daran denken:
eine Preview ist eine Preview ist eine Preview!

Die Idee sieht wie folgt aus und die Umsetzung zeige ich dann im Verlauf des Posts:

Idee

  1. Nutzung der Teams App nur mit verwalteten (und damit COPE/COBO) Geräten
  2. Nutzung der Web Experience nur über MCAS Session Policies die u.a. den Download verhindert
  3. Ggf. Nutzung von Sensitivity Labeln und Verschlüsselung (das soll hier aber kein Thema sein, ich verweise auf meine anderen Posts zu dem Thema).
  4. (Das Thema „Mobile Application Management“ [MAM] behandele ich hier bewusst nicht!)

Umsetzung

Teams App nur mit compliant/managed Devices:

Um zu erreichen, dass die Teams App nur mit Managed Devices genutzt werden kann, muss lediglich eine einfache Conditional Access Policy gesetzt werden:

  1. Eine neue CA Policy erstellen, ihr einen Namen geben und die entsprechenden User auswählen, der Einfachheit halber hier im Bild für alle:
Screenshot: neue CA Policy mit Namen "Users: Block BYOD Teams App" und der Auswahl aller User als Target
  1. die entsprechenden Services auswählen, z.B. Office, SharePoint, Exchange Online und Teams:
Screenshot: weiterer Verlauf der o.g. CA Policy - im Bild die Auswahl der betroffenen Apps: Exchange Online, SharePoint Online, Teams und Office 365

Hinweis: bitte daran denken, dass wenn es um Teams geht auch immer mind. SharePoint mit aufgenommen werden muss, da sonst z.B. der OneDrive Sync möglich wäre – und genau das soll ja hier verhindert werden!

  1. Und jetzt der wichtigste Punkt: unter Conditions->Client Apps alles auswählen, außer dem Browser:
Screenshot: nächstes Bild von der CA Policy im Bereich "Conditions" die Auswahl "Client apps" und dort alles ausgewählt außer "Browser"
  1. Und der zweit wichtigste Punkt: unter Grant->require compliant device aktivieren (Hinweis: das funktioniert nur über in Intune gemanagete Devices, welches durch Intune das Compliance Flag erhalten):
Screenshot: Im Bereich "Access Controls" die Auswahl "Grant: Require device to be marked as compliant"

Einrichten der CA Policy für Teams mit Browser:

Hinweis: die eigentliche Konfiguration des Verhaltens erfolgt erst später in MCAS, hier muss zuerst die „Umleitung“ über CA nach MCAS konfiguriert werden

  1. Wieder zuerst die User auswählen:
Screenshot: neue CA Policy mit Namen "Users: BYOD Teams" und der Auswahl aller User als Target
  1. Und erneut natürlich die Services/Apps auswählen:
Screenshot: weiterer Verlauf der o.g. CA Policy - im Bild die Auswahl der betroffenen Apps: Exchange Online, SharePoint Online, Teams und Office 365
  1. Nun die notwendigen Bedingungen einstellen:
    1. Client apps->Browser
    2. Device state->Exclude: marked as compliant
Screenshot: nächstes Bild von der CA Policy im Bereich "Conditions" die Auswahl "Client apps" und dort lediglich ausgewählt "Browser"
Screenshot: im Bereich "Conditions" bei "Device state (Preview)" die Aktivierung mittels Setzens des Switches bei "Configure" auf "yes" und bei "Exclude" die Anwahl des Hakens "Device marked as compliant"
  1. Last but not least noch die notwendige Session Control setzen:
Screenshot: Diesmal bei "Access Controls" unter "Sessions" die Aktivierung von "Use Conditional Access App Control" mittels des Werts "Use custom policy"

Verbinden von CA mit MCAS

Nachdem nun die beiden CA Policies gesetzt worden sind, muss in MCAS noch die entsprechende(n) Session Policies gesetzt werden.
Damit dies überhaupt möglich ist, muss initial nach der Aktivierung der Policy ein User die betroffenen App(s) besucht haben.

Noch mal deutlich: die Verbindung existiert erst, nachdem ein User, auf den die oben konfigurierte Session Control CA zutrifft, die App genutzt hat.
Einfachster Weg: der konfigurierende Admin macht dies exemplarisch einmalig selbst.

Anschließend stehen in MCAS die Apps unter dem Bereich „Connected Apps->Conditional Access App Control apps“ zur Verfügung:

Screenshot: Ansicht der "Connected Apps->Conditional Access App Control apps", im Bild u.a. Exchange Online, SharePoint Online und Teams

Erstellen der MCAS Policy/Policies

Nachdem wir jetzt sichergestellt haben, dass die richtigen Apps/Appplikationen/Services in MCAS zur Verfügung stehen können wir uns daran begeben die entsprechende(n) Policy/Policies zu erstellen (ganz nach Geschmack, ich beschreibe hier lediglich die Möglichkeit die Downloads auf die lokale Maschine zu verhindern):

  1. Zuerst muss eine neue Session Policy erstellt und als Policy Template „Block download based on real-time content inspection“ zugewiesen werden (Tipp: noch keinen Namen zuweisen, der wird eh in diesem Schritt überschrieben):
Screenshot: Auswahl eines Policy Templates in einer neuen Session Policy
  1. Jetzt ist der richtige Zeitpunkt um der Policy einen individuellen Namen zu geben.
Screenshot: Session Policy nach dem Zuweisen des Templates und Eingabe eines eigenständigen Namens

Wer mag kann die Severity der Policy an dieser Stelle noch anpassen.

  1. Im Template der Policy ist als „Activity Source“ aktuell lediglich die Device Compliance voreingestellt, dort fügen wir noch ein weiteres Kriterium, nämlich die „App“ hinzu:
    1. Klick auf das „+“
    2. Auswahl von „App“ als Filter [durch Klick auf „Select Filter“]
    3. Daraufhin wird automatisch in die Appauswahl gesprungen und wir selektieren die Apps, die wir im Fokus haben, sprich in unserem Fall EXO, SPO, OD4B und Teams
Screenshot: die hinzugefügte Activity Source mit den ausgewählten Apps
  1. Wer möchte kann noch weitere Filter für Dateien setzen, auf die das Downloadverbot angewendet werden soll – z.B. Label, Dateigröße oder -typ, ich setze hier bewusst keinen Filter, da es für alle Dateien gelten soll.
  1. Damit das Verhindern der Downloads überhaupt funktioniert benötigen wir eine „Inspection Method“. Die einfachste Wahl ist „Built-in DLP“, wobei „Use content inspection“ abgewählt ist, da ich jeden Download unterbinden möchte und hier nicht basierend auf dem Inhalt agieren möchte.
    Je nach Einsatzszenario kann dies natürlich sinnvoll sein.
  1. Als Action belasse ich als Auswahl „Block“ und wähle „Create an alert for each matching event with the policy’s severity“ ab, da hier lediglich der Download unterbunden werden soll, ohne, dass dadurch ein Review oder sonstige Arbeiten für das SOC/den Admin gestartet werden sollen.

Nun sind die notwendigen Vorkehrungen geschaffen um den User und die Daten auch in BYOD zu schützen.

User Experience der Policies

Hier nun die Auswirkungen der gesetzten Policies:

  1. User versucht sich mittels der Teams App auf einem BYOD anzumelden:
Screenshot: Fehlermeldung beim Versuch die native Teams App zu nutzen
  1. Login über einen Browser beim Aufruf von https://teams.microsoft.com :
Screenshot: Hinweis auf Monitoring von Teams.

Nach dem Bestätigen des Hinweises auf die Umleitung bekommt man das „normale“ Teamsverhalten angezeigt:

Screenshot: Klassischer Hinweis und Auswahl Teams in der App oder im Browser zu öffnen

(und nein, leider lässt sich dieses Verhalten aktuell nicht ändern, die User müssen daher „wissen“ [Adoption & Change!], dass sie auf „Use the web app instead“ drücken müssen!)

Screenshot: Klassische Teams Ansicht

Wenn eine Office Datei geöffnet wird, so lässt sich diese in Teams ganz normal bearbeiten:

Screenshot: Dokument bearbeiten innerhalb von Teams

Beim Klick auf „Open in Desktop App“ bzw. dem Menüpunkt „Download“ öffent sich Word und nach einem Einloggen erhält der User folgende Fehlermeldung (entsprechend dann auch für die anderen Apps):

Screenshot: Hinweis auf geblockten Inhalt für non-managed Devices

Wenn der User direkt aus der File-Ansicht versucht die Datei herunterzuladen bekommt er folgende Anzeige und auch den Hinwseis in der Textdatei:

Screenshot: Hinweis auf geblockten Download

Dieses Verhalten erhält der User auch, wenn er andere Filetypes herunterladen möchte, die im Browser geöffnet sind, z.B. PDFs.

Bonus: Copy&Paste&Print verhinern:

Den Download alleine zu verhindern ist schon ein gutes Stück auf dem Weg zur Absicherung – jedoch, grade bei sensiblen Informationen, macht es Sinn auch Copy (und ggf. Paste) und vor allem auch das Drucken zu verhindern. Dazu erzeugt man eine zweite Session Policy, die in etwa wie folgt aussehen sollte und dem o.g. Muster entspricht:

Screenshot: Session Policy für das Verhindern von Copy, Paste und Print

Beim Drücken von Strg+C sieht der User dann folgendes:

Screenshot: geblocktes Strg#C

Last but not least ein Hinweis: Ja, mittels dieses Vorgehens verhindere ich natürlich nicht zu 100%, dass ein böswilliger Mitarbeiter Firmengeheimnisse extrahiert (Stw. Screenshot).
Jedoch schütze ich damit, dass Anwender aus Versehen gegen Compliance Richtlinien verstoßen und ohne es zu wollen den eigenen Arbeitgeber in riskante Situationen bringen.
Wer mehr Sicherheit (auch gegen böswillige Mitarbeiter) möchte, der sollte sich die Themen Insider Risk Management, Endpoint DLP und Sensitivity Labeling anschauen und umsetzen.