BYOD richtig gemacht: Ein Praxisleitfaden zum Absichern privater Handys mit Intune
Wer ein kleines Unternehmen auf Microsoft 365 betreibt und geschäftliche E-Mails auf jedem Handy haben will, stößt auf eine Frage, die simpel aussieht und es nicht ist: Wie schützt man Firmendaten auf einem Gerät, das einem nicht gehört?
Die Antwort ist ein Stack klar definierter Tools mit klaren Trade-offs. Richtig eingesetzt, liefern sie starken Schutz für Firmendaten und volle Privatsphäre für persönliche Daten auf demselben Handy. Das hier ist ein Leitfaden zu den Konzepten, den Trade-offs, dem exakten Setup, das wir verwendet haben — und zu den Problemen, in die wir auf dem Weg dorthin gelaufen sind, denn davon gab es einige.
Warum der Aufwand — die Fakten
Ein paar schlichte Gründe, warum es sich lohnt, das ordentlich zu machen:
- Die Handys sind ohnehin privat. Ein kleines Unternehmen verteilt keine Firmenhardware. Die Leute checken E-Mails und Teams auf dem Gerät in ihrer Hosentasche — dieses Gerät ist also längst im Scope, ob man es verwaltet oder nicht.
- Unverwalteter Zugriff ist ein echter Datenpfad. Sich selbst überlassen, liegen Firmen-Mails und -Dateien in Apps ohne Verschlüsselungspflicht, ohne PIN, ohne Kontrolle darüber, wohin Daten kopiert werden — und ohne Möglichkeit, sie zu entfernen, wenn ein Handy verloren geht oder jemand das Unternehmen verlässt.
- Wir verwahren Daten, die zählen. Wir betreiben eine Plattform mit Spielergeldern und personenbezogenen Daten, also halten wir unseren eigenen internen Zugriff an einem definierten Standard (Kontrollen im Stil von CIS/SOC 2), nicht an Best-Effort.
- Privatsphäre ist eine Anforderung, kein Nice-to-have. Was auch immer wir tun — es darf die Reichweite der IT nicht in private Apps, Fotos, Nachrichten oder den Standort von irgendjemandem ausdehnen.
Das Ziel war konkret: Jeder Pfad zu Firmendaten auf einem Handy muss einen definierten Sicherheitsstandard erfüllen, ohne das private Gerät drumherum zu verwalten.
Das Problem, präzise formuliert
Zwei Anforderungen gelten gleichzeitig:
- Firmendaten brauchen Schutz — verschlüsselt, zugriffskontrolliert und entfernbar, wenn ein Handy verloren geht oder die Person das Unternehmen verlässt.
- Ein privates Handy gehört der Person — Fotos, Chats, Apps und Standort bleiben privat und außerhalb der Reichweite der IT.
Mobile Device Management ist das Tooling, das gebaut wurde, um beides gleichzeitig zu erfüllen. Der Rest dieses Leitfadens ist der Werkzeugkasten — und wie die Teile zusammenpassen.
Der Werkzeugkasten: drei Arten, ein Handy zu verwalten
Microsoft Intune bietet ein Spektrum, keinen Schalter:
1. MAM — Mobile Application Management verwaltet die App. Man schützt die Arbeits-Apps und lässt den Rest des Handys in Ruhe. Keine Registrierung.
2. MDM — Mobile Device Management verwaltet das Gerät, in zwei klar unterschiedlichen Varianten:
- Arbeitsprofil / User Enrollment — ein separater, verschlüsselter Arbeitscontainer auf einem privaten Handy. Die IT verwaltet nur den Container.
- Vollständig verwaltet — die IT verwaltet das gesamte Gerät. Angemessen für firmeneigene Hardware, nicht für private Handys.
Die meisten Teams betrachten nur Option 1 und das „vollständig verwaltete“ Ende von Option 2, lehnen beides ab und geben sich mit einer halbgaren Lösung zufrieden. Die nützliche Option ist die in der Mitte.
Konzept 1: MAM / App-Schutz
App-Schutzrichtlinien in Intune sind die MAM-Ebene. Eine Richtlinie, angewendet auf eine App wie Outlook:
- Verschlüsselt Firmendaten innerhalb der App.
- Verlangt eine PIN oder Biometrie zum Öffnen.
- Blockiert
copy,Save AsundOpen invon Firmendaten in private Apps. - Erlaubt einen selektiven Wipe, der nur Firmendaten entfernt und persönliche Daten unangetastet lässt.
Nichts davon erfordert eine Registrierung des Geräts. Das Handy bleibt komplett privat; nur die Arbeits-Apps werden verwaltet. Für viele BYOD-Fälle reicht das — und es war unser Ausgangspunkt.
Konzept 2: Konformität setzt Registrierung voraus
Das Konzept, das alles zusammenhält, ist die Gerätekonformität.
Ein Gerät ist „konform“, wenn es in der Verwaltung registriert ist und die von dir definierten Integritätsregeln erfüllt — Datenträgerverschlüsselung an, Displaysperre gesetzt, OS gepatcht, nicht gerootet und so weiter. Konformität ist ein Zustand, den das Gerät meldet und die Verwaltung überprüft.
Der entscheidende Punkt: Man kann die Konformität eines Geräts nicht bewerten, das nie registriert wurde. Die Prämisse von MAM ist „keine Registrierung“ — ein reines MAM-Handy ist also auf App-Ebene geschützt, kann aber nie „konform“ sein, weil es nichts Registriertes gibt, das man prüfen könnte. Require compliant device und „keine Registrierung“ schließen sich per Design gegenseitig aus.
Wer eine Garantie auf Geräteebene will, muss das Gerät in irgendetwas registrieren. Das führt zur mittleren Option.
Konzept 3: Das Arbeitsprofil
Auf Android ist die mittlere Option ein Arbeitsprofil (über Android Enterprise). Auf iOS heißt das Äquivalent User Enrollment. Das Modell:
Ein Arbeitsprofil ist ein separater, verschlüsselter Container auf einem privaten Handy. Die IT verwaltet nur das, was in diesem Container liegt. Alles außerhalb — private Apps, Fotos, Nachrichten, Konten — liegt in einem Bereich, den die IT weder sehen noch anfassen noch löschen kann.
Arbeits-Apps erscheinen als markiertes Set neben dem persönlichen Startbildschirm, im Container gesandboxt. Das Gerät wird registriert und konform — begrenzt auf den Arbeitscontainer. Persönliche Daten bleiben privat. „Registrierung“ bedeutet hier: Das Unternehmen verwaltet einen Container, nicht das Gerät.
Konzept 4: Bedingter Zugriff
Bedingter Zugriff (Conditional Access, CA) in Microsoft Entra ist das Zugangstor. Bevor eine Anmeldung gewährt wird, prüft er die Bedingungen, die du definierst. Zwei Grants sind hier relevant:
Require app protection— Zugriff ist erlaubt, wenn die App deine MAM-Richtlinie trägt. Passt zu MAM.Require compliant device— Zugriff ist erlaubt, wenn das Gerät registriert und gesund ist. Passt zu MDM / Arbeitsprofil.
CA ist die Stelle, an der du durchsetzt, welches Modell du fährst. Ändere den Grant, und du änderst die Messlatte für den Zugriff.
Der Weg, den wir gegangen sind
Mit dem Modell im Kopf ist der Aufbau geradlinig:
- Mit MAM starten. App-Schutz auf den Arbeits-Apps, plus eine CA-Regel, die App-Schutz verlangt. Der leichteste Eingriff.
- Entscheiden, welche Garantie du brauchst. Wenn „die App ist geschützt“ reicht, hör hier auf — das ist völlig legitim. Wir wollten die Garantie auf Geräteebene.
- Android Enterprise aktivieren, indem du Managed Google Play mit dem Tenant verknüpfst. Eine einmalige Verbindung, die die Arbeitsprofil-Registrierung freischaltet.
- Das Handy als privates Gerät mit Arbeitsprofil registrieren. Ein markierter, verschlüsselter Arbeitsbereich wird erstellt, die private Seite bleibt unberührt, und das Gerät meldet innerhalb weniger Minuten
compliant. - Die Arbeits-Apps ausliefern — in Managed Google Play Outlook, Teams, Edge und die Office-Apps genehmigen, zuweisen, und sie installieren sich in den Container.
- Den CA-Grant umstellen von
Require app protectionaufRequire compliant device— dieselbe Messlatte, die auch für Laptops gilt.
Das ist die saubere Version. Hier ist, was tatsächlich passiert ist.
Probleme, auf die wir gestoßen sind — und wie wir sie gelöst haben
1. Jede verwaltete App blockierte mit „Gerät ist nicht konform“. Unsere MAM-App-Schutzrichtlinie enthielt eine Regel für bedingten Start, appActionIfDeviceComplianceRequired, gesetzt auf block. Als wir sie lockern wollten, akzeptierte Intune nur block oder wipe — die API lehnt null und warn ab. Zusammen mit Konzept 2 ergibt das einen geschlossenen Kreislauf: Die Richtlinie verlangt ein konformes Gerät, ein reines MAM-Handy ist nie registriert, also nie konform, also wird jede App blockiert, und Company Portal versucht immer wieder zu registrieren. Das Ganze wird clientseitig durchgesetzt und taucht deshalb nie als Entra-Anmeldefehler auf — ein Detail, das die Diagnose erschwert.
Fix: Nicht gegen das Tor ankämpfen. Das Gerät registrieren (Arbeitsprofil), damit es tatsächlich konform sein kann, und dann für diese Plattform von MAM weggehen (Problem 5).
2. Company Portal: „erfüllt die Anforderungen für die Registrierung nicht“. Bevor Android Enterprise verbunden war, gab es schlicht keinen Pfad für die Arbeitsprofil-Registrierung — der Registrierungsversuch hatte nichts, worin er landen konnte.
Fix: Managed Google Play verbinden, um Android Enterprise anzubinden. Diese eine Verbindung ist es, die die Arbeitsprofil-Registrierung überhaupt verfügbar macht.
3. Der Google-Konto-Konflikt — der Schritt, der die meiste Zeit gekostet hat. Managed Google Play wird über ein Google-Konto angebunden, das zum Eigentümer des Enterprise wird. Unsere geschäftliche E-Mail-Adresse war bereits mit einem privaten Google-Konto verknüpft, und Google behandelt das als Konto in Konflikt — dieselbe Adresse lässt sich nicht verwenden, um den Organisations-/Workspace-Admin anzulegen. Das übersieht man leicht, und es bringt alles zum Stillstand.
Fix: Den Konflikt zuerst auflösen. Entweder die E-Mail-Adresse über Googles Prozess für Konten in Konflikt freimachen (das bestehende private Google-Konto auf dieser Adresse umbenennen oder schließen) oder ein dediziertes Konto ohne vorherige Google-Registrierung verwenden. Plane dafür echte Zeit ein — das ist das eine Ding, das ein kleines Team am ersten Tag am wahrscheinlichsten blockiert, und es hat nichts mit Intune zu tun.
4. Das Arbeitsprofil war nach der Registrierung leer. Arbeitsprofil-Apps werden nicht von der privaten Seite übernommen. Ein frisch erstellter Container enthält erst einmal nichts.
Fix: Die Apps in Managed Google Play genehmigen und deiner Gruppe als Required (automatische Installation) oder Available (Selbstinstallation aus dem Arbeitsprofil-Store) zuweisen. Danach erscheinen sie als markierte Apps im Container.
5. Immer noch „nicht konform“ — obwohl das Gerät konform war. Das Gerät meldete jetzt compliant, aber Outlook verweigerte weiterhin. Die Ursache: Die MAM-App-Schutzrichtlinie war immer noch derselben App zugewiesen, die jetzt im Arbeitsprofil per MDM verwaltet wurde, und ihr Gerätekonformitäts-Gate kollidierte mit der Registrierung. MAM und MDM wollen dieselbe App nicht gemeinsam verwalten.
Fix: Pro Plattform auf ein Modell festlegen. Wir haben die Zuweisung der Android-App-Schutzrichtlinie entfernt und den Grant im bedingten Zugriff für Android von Require app protection auf Require compliant device umgestellt. Das Arbeitsprofil-Gerät erfüllt ihn direkt; es bleibt kein MAM-Gate übrig, das kollidieren könnte.
6. Unsere eigene Richtlinie blockierte unser Admin-Tooling — AADSTS530033. Beim Automatisieren der Intune-Änderungen wurde eine Admin-Anmeldung verweigert: Der bedingte Zugriff lehnte einen Device-Code-Login ab, weil dieses Token nicht an ein konformes Gerät gebunden ist.
Fix: Privilegierte Arbeit von einem bereits konformen Gerät aus erledigen, damit das Token gerätegebunden ist — z. B. Connect-MgGraph interaktiv von einer verwalteten Maschine. Die Erkenntnis ist positiv: Wenn dein bedingter Zugriff einen Device-Code-Login stoppen kann, ist er richtig konfiguriert.
Über das Bauen mit KI
Wir bauen in der Öffentlichkeit, und wir bauen mit KI — auch im Betrieb. KI ist stark darin, eine Konfiguration schnell durch viele Verzweigungen zu arbeiten. Wir kombinieren das mit einer Regel: Die KI schlägt vor, ein Mensch entscheidet — besonders bei allem, was Sicherheit berührt. Diese Arbeitsteilung lässt ein kleines Team im Tempo eines größeren Teams arbeiten.
Die mentalen Modelle zum Behalten
- MAM verwaltet die App; MDM verwaltet das Gerät. Wähle nach der Garantie, die du brauchst.
- Konformität setzt Registrierung voraus. Man kann kein Gerät überprüfen, das nie registriert wurde —
Require compliant deviceund „keine Registrierung“ können also nicht koexistieren. - Das Arbeitsprofil ist die mittlere Option. Es verwaltet einen Container, nicht das Gerät — Gerätekonformität und persönliche Privatsphäre zugleich.
- Ein Modell pro App. Lass keine MAM-Richtlinie auf einer App liegen, die du zu MDM umgezogen hast; entscheide dich für eine Spur.
- Der bedingte Zugriff setzt die Messlatte. Wähle den Grant, der zu deinem Modell passt, und lass ihn durchsetzen.
Wir stecken dieses Maß an Sorgfalt in eine Handvoll Arbeitspostfächer, weil dieselbe Disziplin, die unseren mobilen Zugriff absichert, auch dein Konto, deine Gelder und deine Daten auf der Plattform schützt. Sicherheit ist eine Gewohnheit, die sich durch die interne Arbeit zieht — nicht nur durch die Teile, die Kunden sehen.
Wir sehen uns an den Tischen.
The Salty Korean
Gründer des Salty Poker Network. Schreibt über Texas-Poker, Plattformaufbau und die Zukunft des Online-Pokers. Mehr lesen auf The Salty Korean.