Übersicht über App-Schutzrichtlinien

  • Artikel

Intune-App-Schutzrichtlinien (App Protection Policies, APP) sind Regeln, die sicherstellen, dass die Daten einer organization sicher bleiben oder in einer verwalteten App enthalten bleiben. Mit diesen Richtlinien können Sie steuern, wie auf Daten von Apps auf mobilen Geräten zugegriffen und von ihnen freigegeben wird. Eine Richtlinie kann eine Regel sein, die erzwungen wird, wenn ein Benutzer versucht, auf „unternehmenseigene“ Daten zuzugreifen oder diese zu verschieben. Es kann sich auch um eine Reihe von Aktionen handeln, die nicht zulässig sind oder überwacht werden, wenn sich ein Benutzer in der App befindet. Eine verwaltete App in Intune ist eine geschützte App , auf die Intune-App-Schutzrichtlinien angewendet und von Intune verwaltet werden.

Die Verwendung von Intune-App-Schutzrichtlinien bietet mehrere Vorteile , darunter der Schutz von Unternehmensdaten auf mobilen Geräten, ohne dass eine Geräteregistrierung erforderlich ist, und die Steuerung, wie auf Daten von Apps auf mobilen Geräten zugegriffen und freigegeben wird.

Beispiele für die Verwendung von App-Schutzrichtlinien mit Microsoft Intune:

  • Anfordern einer PIN oder eines Fingerabdrucks für den Zugriff auf Unternehmens-E-Mails auf einem mobilen Gerät
  • Verhindern des Kopierens und Einfügens von Unternehmensdaten in persönliche Apps durch Benutzer
  • Beschränken des Zugriffs auf Unternehmensdaten auf genehmigte Apps

Viele Produktivitäts-Apps, z. B. microsoft 365 (Office)-Apps, können mit Intune MAM verwaltet werden. Weitere Informationen finden Sie in der offiziellen Liste mit von Microsoft Intune geschützten Apps, die für die Öffentlichkeit verfügbar sind.

Wie Sie Ihre App-Daten schützen können

Ihre Mitarbeiter verwenden mobile Geräte sowohl für private als auch für berufliche Zwecke. Während Ihre Angestellten also weiterhin produktiv sein können, Sie werden gleichzeitig beabsichtigten und unbeabsichtigten Datenverlust verhindern wollen. Sie sollten auch Unternehmensdaten schützen, auf die von Geräten zugegriffen wird, die nicht von Ihnen verwaltet werden.

Sie können Intune-App-Schutzrichtlinien unabhängig von jeglicher mobilen Geräteverwaltungslösung verwenden. Diese Unabhängigkeit hilft Ihnen, die Daten Ihres Unternehmens mit oder ohne Registrierung von Geräten in einer Geräteverwaltungslösung zu schützen. Durch die Implementierung von Richtlinien auf App-Ebene können Sie den Zugriff auf Unternehmensressourcen einschränken und Daten im Zuständigkeitsbereich der IT-Abteilung halten.

App-Schutzrichtlinien auf Geräten

App-Schutzrichtlinien können für Apps konfiguriert werden, die auf Geräten ausgeführt werden, die folgende Voraussetzungen erfüllen:

  • Registriert bei Microsoft Intune: Diese Geräte sind in der Regel unternehmenseigene Geräte.

  • Registriert in einer Lösung für die Verwaltung mobiler Geräte (Mobile Device Management, MDM) eines Drittanbieters: Diese Geräte befinden sich in der Regel im Besitz des Unternehmens.

    Hinweis

    Verwaltungsrichtlinien für mobile Apps sollten nicht in Verbindung mit Verwaltungslösungen für mobile Geräte von Drittanbietern oder sicheren Containerlösungen verwendet werden.

  • Nicht bei einer Lösung für die Verwaltung mobiler Geräte registriert: Diese Geräte sind in der Regel mitarbeitereigene Geräte, die weder bei Intune noch anderen MDM-Lösungen registriert sind oder dort verwaltet werden.

Wichtig

Sie können Verwaltungsrichtlinien für mobile Apps für mobile Office-Apps erstellen, die eine Verbindung mit Microsoft 365-Diensten herstellen. Außerdem können Sie den Zugriff auf lokale Exchange-Postfächer schützen, indem Sie Intune-App-Schutzrichtlinien für Outlook für iOS/iPadOS und Android erstellen, die mit hybrider moderner Authentifizierung aktiviert wurden. Bevor Sie dieses Feature verwenden, sollten Sie sicherstellen, dass Sie die Anforderungen für Outlook für iOS/iPadOS und Android erfüllen. App-Schutzrichtlinien werden nicht für andere Apps unterstützt, die eine Verbindung mit lokalen Exchange- oder SharePoint-Diensten herstellen.

Vorteile der Verwendung von App-Schutzrichtlinien

Im Folgenden finden Sie die wichtigsten Vorteile von App-Schutzrichtlinien:

  • Schutz Ihrer Unternehmensdaten auf App-Ebene. Da die Verwaltung von mobilen Apps keine Geräteverwaltung voraussetzt, können Sie Unternehmensdaten auf verwalteten und auf nicht verwalteten Geräten schützen. Bei der Verwaltung wird die Benutzeridentität in den Mittelpunkt gestellt, wodurch sich die Geräteverwaltung erübrigt.

  • Die Produktivität der Endbenutzer wird nicht beeinträchtigt, und Richtlinien werden nicht angewendet, wenn die App in einem privaten Kontext verwendet wird. Die Richtlinien werden nur auf den beruflichen Kontext angewendet, wodurch Sie die Möglichkeit haben, Unternehmensdaten zu schützen, ohne dass private Daten einbezogen werden.

  • Mit Appschutz-Richtlinien wird sichergestellt, dass der Schutz auf App-Ebene erfolgt. Sie haben beispielsweise folgende Möglichkeiten:

    • Anfordern einer PIN zum Öffnen einer App in einem geschäftlichen Kontext
    • Steuern des Teilens von Daten zwischen Apps
    • Verhindern des Speicherns von Unternehmens-App-Daten an einem privaten Speicherort

  • Eine MDM-Lösung stellt zusätzlich zu MAM sicher, dass das Gerät geschützt ist. So können Sie beispielsweise die Eingabe einer PIN für den Zugriff auf das Gerät anfordern, oder Sie können verwaltete Apps auf dem Gerät bereitstellen. Sie können Apps auch über die MDM-Lösung auf Geräten bereitstellen, um mehr Kontrolle über die App-Verwaltung zu haben.

Es gibt weitere Vorteile bei der Verwendung einer MDM mit App-Schutzrichtlinien, und Unternehmen können App-Schutzrichtlinien sowohl mit als auch ohne MDM gleichzeitig verwenden. Nehmen Sie beispielsweise weinen Mitarbeiter an, der sowohl ein unternehmenseigenes Smartphone als auch seinen privaten Tablet verwendet. Das unternehmenseigene Smartphone wird in einer MDM registriert und von App-Schutzrichtlinien geschützt, während das private Gerät nur von App-Schutzrichtlinien geschützt wird.

Wenn Sie eine MAM-Richtlinie auf den Benutzer anwenden, ohne den Gerätezustand festzulegen, erhält der Benutzer die MAM-Richtlinie sowohl auf dem BYOD-Gerät als auch auf dem mit Intune verwalteten Gerät. Sie können eine MAM-Richtlinie auch basierend auf dem verwalteten Zustand anwenden. Wenn Sie also eine App-Schutzrichtlinie erstellen, wählen Sie in diesem Fall neben Auf alle App-Typen ausrichten die Option Nein aus. Gehen Sie dann auf eine der folgenden Arten vor:

  • Wenden Sie eine weniger strenge MAM-Richtlinie auf mit Intune verwaltete Geräte an, und wenden Sie eine restriktivere MAM-Richtlinie auf nicht bei MDM registrierte Geräte an.
  • Wenden Sie eine MAM-Richtlinie nur auf nicht registrierte Geräte an.

Unterstützte Plattformen für App-Schutzrichtlinien

Intune bietet eine Reihe von Funktionen, die Ihnen dabei helfen, die benötigten Apps auf jene Geräte zu übertragen, auf denen sie ausgeführt werden sollen. Weitere Informationen finden Sie unter App-Verwaltungsfunktionen nach Plattform.

Die Plattform für Schutzrichtlinien für Intune-Apps ist auf die Plattformunterstützung für mobile Office-Anwendungen für Android- und iOS/iPadOS-Geräte ausgerichtet. Weitere Informationen finden Sie im Abschnitt Mobile Apps unter Systemanforderungen für Office.

Vorschau: Darüber hinaus können Sie App-Schutzrichtlinien für Windows-Geräte erstellen. Weitere Informationen finden Sie unter App-Schutz Erfahrung für Windows-Geräte.

Wichtig

Das Intune-Unternehmensportal ist auf dem Gerät erforderlich, damit das Gerät App-Schutzrichtlinien unter Android empfangen kann.

Datenschutzframework für App-Schutzrichtlinien

Die in den App-Schutzrichtlinien verfügbaren Optionen ermöglichen Organisationen, den Schutz an ihre speziellen Anforderungen anzupassen. Für einige Organisationen ist es jedoch möglicherweise nicht offensichtlich, welche Richtlinieneinstellungen genau erforderlich sind, um ein vollständiges Szenario zu implementieren. Um Unternehmen bei der Priorisierung der Absicherung mobiler Clientendpunkte zu unterstützen, hat Microsoft für die Verwaltung mobiler iOS- und Android-Apps eine Taxonomie für sein Datenschutzframework für App-Schutzrichtlinien eingeführt.

Dieses Datenschutzframework ist in drei Konfigurationsebenen unterteilt, wobei jede Ebene auf der vorherigen Ebene aufbaut:

  • Einfacher Datenschutz für Unternehmen (Ebene 1): Diese Ebene stellt sicher, dass Apps mit einer PIN geschützt und verschlüsselt sind, und dient zum Durchführen selektiver Löschvorgänge. Bei Android-Geräten überprüft diese Ebene den Android-Gerätenachweis. Dabei handelt es sich um eine Konfiguration auf Einstiegsebene, die ähnliche Datenschutzkontrolle in Exchange Online-Postfachrichtlinien bereitstellt und der IT sowie dem Benutzerstamm eine Einführung in App-Schutzrichtlinien bietet.
  • Erweiterter Datenschutz für Unternehmen (Ebene 2): Diese Ebene führt Mechanismen für App-Schutzrichtlinien zur Verhinderung von Datenlecks sowie die mindestens zu erfüllenden Betriebssystemanforderungen ein. Dies ist die Konfiguration, die für die meisten mobilen Benutzer gilt, die auf Geschäfts-, Schul- oder Unidaten zugreifen.
  • Hoher Datenschutz für Unternehmen (Ebene 3): Auf dieser Ebene werden Mechanismen zum erweiterten Datenschutz, eine verbesserte PIN-Konfiguration sowie Mobile Threat Defense für App-Schutzrichtlinien eingeführt. Diese Konfiguration ist für Benutzer vorgesehen, die auf Hochrisikodaten zugreifen.

Die spezifischen Empfehlungen für jede Konfigurationsebene sowie die minimalen zu schützenden Apps finden Sie unter Datenschutzframework mithilfe von App-Schutzrichtlinien.

So schützen App-Schutzrichtlinien Ihre App-Daten

Apps ohne App-Schutzrichtlinien

Wenn Apps ohne Einschränkungen verwendet werden, können Unternehmensdaten und private Daten vermischt werden. Unternehmensdaten können damit an Speicherorten wie dem persönlichen Speicher abgelegt oder an Apps außerhalb Ihres Zuständigkeitsbereichs übermittelt werden, was Datenverlust bedeuten würde. Die Pfeile im folgenden Diagramm zeigen die uneingeschränkte Datenverschiebung zwischen sowohl unternehmenseigenen als auch persönlichen Apps sowie zu Speicherorten.

Darstellung der Datenverschiebung zwischen Apps ohne Richtlinien

Datenschutz mit App-Schutzrichtlinien

Mit App-Schutzrichtlinien können Sie verhindern, dass Unternehmensdaten im lokalen Speicher des Geräts gespeichert werden (siehe folgende Abbildung). Außerdem können Sie das Verschieben von Daten in andere Apps einschränken, die nicht durch App-Schutzrichtlinien geschützt sind. Einstellungen für App-Schutzrichtlinien:

  • Datenverschiebungsrichtlinien wie Speichern von Kopien von Organisationsdaten und Ausschneiden, Kopieren und Einfügen einschränken.
  • Einstellungen von Zugriffsrichtlinien wie Einfache PIN für den Zugriff erforderlich und Ausführen verwalteter Apps auf mit Jailbreak oder Rooting manipulierten Geräten blockieren.

Darstellung von Unternehmensdaten, die durch Richtlinien geschützt werden

Schutz von Daten mit App-Schutzrichtlinien auf Geräten, die durch eine MDM-Lösung verwaltet werden

Die folgende Abbildung zeigt die Schutzebenen, die durch den gemeinsamen Einsatz von MDM und App-Schutzrichtlinien bereitgestellt werden.

Die Abbildung zeigt, wie App-Schutzrichtlinien auf BYOD-Geräten funktionieren

Die MDM-Lösung bietet einen Mehrwert durch Folgendes:

  • Registrieren das Gerät
  • Stellt die Apps auf dem Gerät bereit
  • Sorgt für kontinuierliche Gerätekonformität und -verwaltung

Die App-Schutzrichtlinien bieten einen Mehrwert durch Folgendes:

  • Schutz der Unternehmensdaten vor dem Zugriff durch Verbraucher-Apps und -Dienste
  • Anwenden von Einschränkungen, z. B. für Speichern unter, Zwischenablage oder PIN, auf Client-Apps
  • Löschen von Unternehmensdaten aus Apps bei Bedarf, ohne die Apps vom Gerät zu entfernen

Schutz von Daten mit App-Schutzrichtlinien für Geräte ohne Registrierung

Das folgende Diagramm zeigt, wie die Datenschutzrichtlinien auf App-Ebene ohne MDM funktionieren.

Die Abbildung zeigt, wie App-Schutzrichtlinien auf Geräten ohne Registrierung (nicht verwalteten Geräten) funktionieren.

Bei BYOD-Geräten, die nicht in einer MDM-Lösung registriert sind, können App-Schutzrichtlinien dazu beitragen, Unternehmensdaten auf App-Ebene zu schützen. Es gibt jedoch einige Einschränkungen, die Sie kennen sollten:

  • Sie können auf dem Gerät keine Apps bereitstellen. Der Endbenutzer muss die Apps aus dem Store beziehen.
  • Sie können auf diesen Geräten keine Zertifikatprofile bereitstellen.
  • Sie können auf diesen Geräten keine unternehmensweiten WLAN- und VPN-Einstellungen bereitstellen.

Apps, die mit App-Schutzrichtlinien verwaltet werden können

Jede App, die in das Intune SDK integriert oder vom Intune App Wrapping Tool umschlossen wurde, kann mithilfe von Intune-App-Schutzrichtlinien verwaltet werden. Weitere Informationen finden Sie in der offiziellen Liste der durch Microsoft Intune geschützten Apps, die mithilfe dieser Tools erstellt wurden und für die öffentliche Nutzung verfügbar sind.

Das Intune SDK-Entwicklungsteam testet und unterstützt aktiv Apps, die mit den nativen Android-, iOS/iPadOS-Plattformen (Obj-C, Swift), Xamarin- und Xamarin.Forms-Plattformen erstellt wurden. Während einige Kunden das Intune SDK erfolgreich in andere Plattformen wie React Native und NativeScript integrieren konnten, bieten wir keine expliziten Anleitungen oder Plug-Ins für App-Entwickler, die andere als unsere unterstützten Plattformen verwenden.

Anforderungen an die Endbenutzer bei der Verwendung von App-Schutzrichtlinien

Die folgende Liste enthält die Anforderungen, die für Endbenutzer bei der Verwendung von App-Schutzrichtlinien in einer mit Intune verwalteten App erfüllt sein müssen:

App-Schutz-Richtlinien für Microsoft 365-Apps (Office)

Es gibt einige zusätzliche Anforderungen, die Sie beachten sollten, wenn Sie App-Schutz Richtlinien mit Microsoft 365 (Office)-Apps verwenden.

Mobile Outlook-App

Für die Verwendung der mobilen Outlook-App gelten u. a. folgende zusätzliche Anforderungen:

  • Die mobile Outlook-App muss auf dem Gerät des Endbenutzers installiert sein.

  • Der Endbenutzer muss über ein Microsoft 365 Exchange Online Postfach und eine Lizenz verfügen, die mit dem Microsoft Entra-Konto verknüpft ist.

    Hinweis

    Die mobile Outlook-App unterstützt derzeit nur den Intune-App-Schutz für Microsoft Exchange Online und Exchange Server mit moderner hybrider Authentifizierung, nicht jedoch lokales Exchange oder Exchange in Office 365.

Word, Excel und PowerPoint

Für die Verwendung der Apps für Word, Excel und PowerPoint gelten u. a. folgende zusätzliche Anforderungen:

  • Der Endbenutzer muss über eine Lizenz für Microsoft 365 Apps for Business oder ein Unternehmen verfügen, die mit dem Microsoft Entra Konto verknüpft ist. Das Abonnement muss die Office-Apps auf mobilen Geräten enthalten und kann ein Cloudspeicherkonto mit OneDrive for Business umfassen. Microsoft 365-Lizenzen können im Microsoft 365 Admin Center zugewiesen werden. Befolgen Sie dazu diese Anweisungen.

  • Der Benutzer muss über einen verwalteten Speicherort verfügen, der mithilfe der Funktion „Speichern unter“ im Rahmen der Einstellung für die Anwendungsschutzrichtlinie „Kopien von Organisationsdaten speichern“ konfiguriert wird. Wenn beispielsweise der verwaltete Speicherort OneDrive ist, muss die OneDrive-App in der Word-, Excel- oder PowerPoint-App des Endbenutzer konfiguriert werden.

  • Wenn der verwaltete Speicherort OneDrive ist, muss die App unter die App-Schutzrichtlinie fallen, die für den Endbenutzer angegeben ist.

    Hinweis

    Die mobilen Office-Apps unterstützen zurzeit nur SharePoint Online, nicht jedoch SharePoint lokal.

Verwalteter Speicherort für Office erforderlich

Für Office wird ein verwalteter Speicherort (z. B. OneDrive) benötigt. Intune kennzeichnet alle Daten in der App entweder als „unternehmenseigen“ oder „persönlich“. Daten werden als „unternehmenseigen“ betrachtet, wenn sie von einem Speicherort des Unternehmens stammen. Bei den Office-Apps betrachtet Intune Folgendes als Unternehmensspeicher: E-Mail-Speicher (Exchange) oder Cloudspeicher (OneDrive-App mit einem OneDrive for Business-Konto).

Skype for Business

Für die Verwendung von Skype for Business gelten zusätzliche Anforderungen. Informationen hierzu finden Sie in den Lizenzanforderungen für Skype for Business. Informationen zu Skype for Business hybriden und lokalen Konfigurationen (SfB) finden Sie unter Hybrid Modern Auth for SfB and Exchange goes GA und Modern Auth für SfB OnPrem mit Microsoft Entra ID.

Globale App-Schutzrichtlinie

Wenn ein OneDrive-Administrator zu admin.onedrive.com navigiert und Gerätezugriff auswählt, kann er Steuerelemente für die Mobile Anwendungsverwaltung für die OneDrive- und SharePoint-Client-Apps festlegen.

Die Einstellungen, die für die OneDrive-Administratorkonsole zur Verfügung gestellt wurden, konfigurieren eine besondere App-Schutzrichtlinie für Intune, die globale Richtlinie. Diese globale Richtlinie gilt für alle Benutzer in Ihrem Mandanten und kann nicht eingeschränkt angewendet werden.

Sobald sie aktiviert ist, werden die OneDrive- und SharePoint-Apps für iOS/iPadOS und Android standardmäßig über die ausgewählten Einstellungen geschützt. Ein IT-Experte kann diese Richtlinie im Microsoft Intune Admin Center bearbeiten, um gezieltere Apps hinzuzufügen und richtlinieneinstellungen zu ändern.

Standardmäßig darf nur eine globale Richtlinie pro Mandant vorhanden sein. Intune Graph-APIs können Sie jedoch verwenden, um zusätzliche globale Richtlinien pro Mandant zu erstellen, was jedoch nicht empfohlen wird. Das Erstellen zusätzlicher globaler Richtlinien wird nicht empfohlen, da die Problembehandlung bei der Implementierung einer solchen Richtlinie sehr kompliziert sein kann.

Obwohl die globale Richtlinie für alle Benutzer in Ihrem Mandanten gilt, werden diese Einstellungen von jeder standardmäßigen App-Schutzrichtlinie für Intune überschrieben.

Hinweis

Die Richtlinieneinstellungen im OneDrive Admin Center werden nicht mehr aktualisiert. Microsoft Intune können stattdessen verwendet werden. Weitere Informationen finden Sie unter Steuern des Zugriffs auf Features in den mobilen OneDrive- und SharePoint-Apps.

App-Schutzfunktionen

Mehrere Identitäten

Mit der Unterstützung mehrerer Identitäten kann eine App mehrere Zielgruppen unterstützen. Hierbei kann es sich sowohl um „Unternehmensbenutzer“ als auch um „persönliche Benutzer“ handeln. Geschäfts-, Schul- und Unikonten werden von "Unternehmenszielgruppen" verwendet, während persönliche Konten für Verbrauchergruppen wie Microsoft 365 (Office)-Benutzer verwendet werden. Eine App, die mehrere Identitäten unterstützt, kann öffentlich freigegeben werden. Dabei werden App-Schutzrichtlinien nur angewendet, wenn die App im Kontext eines Geschäfts-, Schul- und Unikontos („Unternehmen“) verwendet wird. Bei der Unterstützung mehrerer Identitäten wird das Intune SDK verwendet, um App-Schutzrichtlinien nur auf das Geschäfts-, Schul- oder Unikonto anzuwenden, das bei der App angemeldet ist. Wenn ein persönliches Konto bei der App angemeldet ist, kann nicht auf die Daten zugegriffen werden. App-Schutzrichtlinien können verwendet werden, um zu verhindern, dass Daten von Geschäfts-, Schul- oder Unikonten an persönliche Konten innerhalb der App mit mehreren Identitäten, an persönliche Konten mit anderen Apps oder persönliche Apps übertragen werden.

Wichtig

Unabhängig davon, ob eine App Multiidentität unterstützt, kann nur auf eine einzelne "Unternehmensidentität" eine Intune App Protection-Richtlinie angewendet werden.

Ein Beispiel: Wenn ein Benutzer ein neues Dokument in Word startet, wird dies als „persönlicher“ Kontext betrachtet, und die App-Schutzrichtlinien von Intune werden nicht angewendet. Sobald das Dokument im OneDrive-„Unternehmenskonto“ gespeichert wird, gilt dies als „Unternehmenskontext“, und die Intune-App-Schutzrichtlinien werden angewendet.

Sehen Sie sich die folgenden Beispiele für die Arbeit oder den Unternehmenskontext an:

  • Ein Benutzer startet die OneDrive-App über sein Geschäftskonto. Im geschäftlichen Kontext kann er keine Dateien an einen privaten Speicherort verschieben. Wenn der Benutzer OneDrive später jedoch mit einem persönlichen Konto verwendet, kann er Daten ohne Einschränkung aus dem persönlichen OneDrive kopieren und verschieben.
  • Ein Benutzer beginnt, eine E-Mail in der Outlook-App zu verfassen. Sobald der Betreff oder der Nachrichtentext aufgefüllt ist, kann der Benutzer die FROM-Adresse („An“) nicht mehr vom Arbeitskontext in den persönlichen Kontext umstellen, da der Betreff und der Nachrichtentext durch die App-Schutzrichtlinie geschützt sind.

Hinweis

Outlook bietet eine kombinierte Ansicht für „persönliche“ und „geschäftliche“ E-Mails. In dieser Situation fordert die Outlook-App beim Start zur Eingabe der Intune-PIN auf.

Wichtig

Obwohl Microsoft Edge im „Unternehmenskontext“ ausgeführt wird, können Benutzer OneDrive-Dateien aus dem „Unternehmenskontext“ absichtlich in einen unbekannten persönlichen Cloudspeicherort verschieben. Um dies zu vermeiden, finden Sie weitere Informationen unter Verwalten eingeschränkter Websites und „Konfigurieren der Liste zulässiger/blockierter Websites für Microsoft Edge“.

Intune-App-PIN

Die PIN (Personal Identification Number) ist eine Kennung, mit der sichergestellt wird, dass der richtige Benutzer in einer Anwendung auf die Daten der Organisation zugreift.

Aufforderung zur Eingabe der PIN
Intune fordert den Benutzer zur Eingabe seiner App-PIN auf, wenn dieser versucht, auf „unternehmenseigene“ Daten zuzugreifen. In Apps mit Unterstützung mehrerer Identitäten – z. B. Word, Excel oder PowerPoint – wird der Benutzer zur PIN-Eingabe aufgefordert, wenn er versucht, ein „unternehmenseigenes“ Dokument oder eine „unternehmenseigene“ Datei zu öffnen. In Apps mit nur einer Identität – z. B. branchenspezifische Apps, die über das Intune App Wrapping Tool verwaltet werden – wird der Benutzer beim Start der App zur Eingabe der PIN aufgefordert, da dem Intune SDK bekannt ist, dass die Verwendung der App immer „unternehmenseigen“ ist.

Häufigkeit der Aufforderung zur Eingabe der PIN oder Administratoranmeldeaufforderung eines Unternehmens
Der IT-Administrator kann die Intune-App-Schutzrichtlinieneinstellung Im Microsoft Intune Admin Center die Zugriffsanforderungen nach (Minuten) erneut überprüfen definieren. Diese Einstellung gibt die Zeitspanne an, nach der die Zugriffsanforderungen auf dem Gerät überprüft werden und der Bildschirm zur Eingabe der PIN oder Administratoranmeldeaufforderung eines Unternehmens erneut angezeigt wird. Folgende Faktoren beeinflussen, wie häufig ein Benutzer zur PIN-Eingabe aufgefordert wird:

  • Eine PIN wird für alle Apps des gleichen Herausgebers genutzt, um die Benutzerfreundlichkeit zu erhöhen:
    In iOS/iPadOS wird eine gemeinsame App-PIN für alle Apps des gleichen App-Herausgebers genutzt. Beispielsweise verwenden alle Microsoft-Apps dieselbe PIN. Unter Android wird eine App-PIN für alle Apps genutzt.
  • Das Verhalten von Zugriffsanforderungen nach (Minuten) erneut überprüfen nach einem Geräteneustart:
    Ein Timer zählt die Anzahl von Minuten der Inaktivität, die angeben, wann die Intune-App-PIN oder Administratoranmeldeaufforderung eines Unternehmens das nächste Mal angezeigt werden soll. Unter iOS/iPadOS hat ein Neustart des Geräts keine Auswirkung auf den Timer. Das bedeutet, dass ein Neustart des Geräts keine Auswirkung auf die Anzahl der inaktiven Minuten des Benutzers einer iOS/iPadOS-App mit der Intune-PIN-Richtlinie (oder Administratoranmeldeaufforderungs-Richtlinie) hat. Unter Android wird der Timer beim Neustart des Geräts zurückgesetzt. Deshalb ist es wahrscheinlich, dass Android-Apps mit der Intune-PIN-Richtlinie (oder Administratoranmeldeaufforderungs-Richtlinie) den Benutzer unabhängig vom Wert der Einstellung „Zugriffsanforderungen erneut überprüfen nach (Minuten)“ nach dem Neustart des Geräts zur Eingabe einer PIN oder Administratoranmeldeaufforderung eines Unternehmens für die App auffordern.
  • Das Wiederholungsverhalten des Timers für die PIN:
    Wenn für den Zugriff auf eine App (App A) eine PIN eingegeben wurde und diese App auf dem Gerät nicht mehr im Vordergrund (Haupteingabefokus) ausgeführt wird, wird der Timer für diese PIN zurückgesetzt. Eine andere App (App B), für die dieselbe PIN gilt, fordert den Benutzer nicht zur PIN-Eingabe auf, weil der Zeitgeber zurückgesetzt wurde. Die Aufforderung wird wieder angezeigt, wenn der Wert für „Zugriffsanforderungen nach (Minuten) erneut überprüfen“ erneut erreicht wurde.

Selbst wenn die PIN auf iOS/iPadOS-Geräten von mehreren Apps von verschiedenen Herausgebern genutzt wird, wird die Eingabeaufforderung noch mal angezeigt, wenn der Wert für Zugriffsanforderungen nach (Minuten) erneut überprüfen nochmals für die App erreicht wird, die nicht über den Eingabefokus verfügt. Beispiel: Der Benutzer verfügt über die App A von Herausgeber X und über die App B von Herausgeber Y, und für diese Apps wird die gleiche PIN verwendet. Der Benutzer verwendet App A (im Vordergrund), und die App B ist minimiert. Wenn der Wert für Zugriffsanforderungen nach (Minuten) erneut überprüfen erreicht wurde und der Benutzer zur App B wechselt, ist eine PIN erforderlich.

Hinweis

Um die Zugriffsanforderungen des Benutzers (besonders bei häufig verwendeten Apps) öfter zu überprüfen (z. B. die PIN-Eingabeaufforderung), empfiehlt es sich, den Wert für die Einstellung „Zugriffsanforderungen nach (Minuten) erneut überprüfen“ zu senken.

Integrierte App-PINs für Outlook und OneDrive
Die Intune-PIN funktioniert mit einem auf Inaktivität basierten Timer, also dem Wert von Zugriffsanforderungen nach (Minuten) erneut überprüfen. Deshalb werden Aufforderungen zur Eingabe der Intune-PIN unabhängig von Aufforderungen zur Eingabe der integrierten App-PIN für Outlook und OneDrive, die standardmäßig beim Start der App angezeigt werden, angezeigt. Wenn der Benutzer gleichzeitig zur Eingabe beider PINs aufgefordert wird, sollte die Intune-PIN Vorrang haben.

Sicherheit für Intune-PINs
Mit der PIN wird sichergestellt, dass nur der richtige Benutzer in der App auf Daten der Organisation zugreifen kann. Ein Endbenutzer muss sich daher mit seinem Geschäfts-, Uni- oder Schulkonto anmelden, bevor er seine Intune-App-PIN festlegen oder zurücksetzen kann. Diese Authentifizierung wird von Microsoft Entra ID über einen sicheren Tokenaustausch verarbeitet und ist für das Intune SDK nicht transparent. Hinsichtlich der Sicherheit ist die beste Möglichkeit, ein Geschäfts-, Uni- oder Schulkonto zu schützen, das Konto zu verschlüsseln. Die Verschlüsselung steht nicht in Zusammenhang mit der App-PIN, sondern stellt eine eigene App-Schutzrichtlinie dar.

Schutz vor Brute-Force-Angriffen und der Intune-PIN
Im Rahmen der App-PIN-Richtlinie kann der IT-Administrator festlegen, wie oft ein Benutzer versuchen kann, die PIN zu authentifizieren, bevor die App gesperrt wird. Nachdem die maximale Anzahl von Versuchen erreicht wurde, kann das Intune SDK die „unternehmenseigenen“ Daten aus der App entfernen.

Intune-PIN und selektives Zurücksetzen
Unter iOS/iPadOS werden die PIN-Informationen auf App-Ebene im Schlüsselbund gespeichert, der von Apps desselben Herausgebers, wie z. B. allen Apps von Microsoft als Erstanbieter, gemeinsam genutzt wird. Diese PIN-Informationen sind auch an ein Endbenutzerkonto gebunden. Ein selektives Zurücksetzen einer App darf keine Auswirkung auf eine andere App haben.

Beispielsweise wird eine für Outlook festgelegte PIN für den angemeldeten Benutzer in einem gemeinsam genutzten Schlüsselbund gespeichert. Wenn sich der Benutzer bei OneDrive (auch ein Microsoft-Produkt) anmeldet, wird die gleiche PIN wie bei Outlook verwendet, da derselbe gemeinsam genutzte Schlüsselbund zum Einsatz kommt. Wenn sich der Benutzer aus Outlook abmeldet oder die Benutzerdaten in Outlook zurückgesetzt werden, löscht das Intune SDK diesen Schlüsselbund nicht, da OneDrive diese PIN möglicherweise noch immer verwendet. Aus diesem Grund wird beim selektiven Zurücksetzen der gemeinsam genutzte Schlüsselbund, einschließlich PIN, nicht gelöscht. Dieses Verhalten bleibt auch dann unverändert, wenn nur eine App eines Herausgebers auf dem Gerät vorhanden ist.

Die PIN wird von Apps desselben Herausgebers gemeinsam genutzt. Wenn das Zurücksetzen für eine einzelne App erfolgt, weiß das Intune SDK nicht, ob sich auf dem Gerät weitere Apps desselben Herausgebers befinden. Daher löscht das Intune SDK die PIN nicht, da sie möglicherweise noch von anderen Apps verwendet wird. Es wird erwartet, dass die PIN der App zurückgesetzt wird, wenn die letzte App dieses Herausgebers im Rahmen einer Betriebssystembereinigung endgültig entfernt wird.

Wenn Sie feststellen, dass die PIN auf einigen Geräten gelöscht wird, geschieht wahrscheinlich Folgendes: Da die PIN an eine Identität gebunden ist, wird der Benutzer, der sich nach einer Zurücksetzung mit einem anderen Konto angemeldet hat, aufgefordert, eine neue PIN einzugeben. Wenn er sich jedoch mit einem zuvor bestehenden Konto anmeldet, kann eine bereits im Schlüsselbund gespeicherte PIN zur Anmeldung verwendet werden.

Doppeltes Festlegen einer PIN für Apps vom gleichen Herausgeber?
MAM (unter iOS/iPadOS) ermöglicht derzeit eine PIN auf Anwendungsebene mit alphanumerischen und Sonderzeichen (als "Kennung" bezeichnet), die die Teilnahme von Anwendungen (d. h. WXP, Outlook, Managed Browser, Viva Engage) erfordert, um das Intune SDK für iOS zu integrieren. Ohne das SDK werden die Kennungseinstellungen nicht ordnungsgemäß für die Zielanwendungen erzwungen. Dies war ein Feature, das im Intune SDK für iOS v. 7.1.12 veröffentlicht wurde.

Alle numerischen PINs oder Kennungen in Version 7.1.12 oder höher werden getrennt von der numerischen PIN in früheren Versionen des SDK verarbeitet, um dieses Feature zu unterstützen und die Abwärtskompatibilität mit früheren Versionen des Intune SDK für iOS/iPadOS zu gewährleisten. Eine weitere Änderung wurde im Intune SDK für iOS v 14.6.0 eingeführt, die bewirkt, dass alle PINs in 14.6.0+ getrennt von PINS in früheren Versionen des SDK behandelt werden.

Wenn also ein Gerät Anwendungen mit Intune SDK für iOS-Versionen zwischen 7.1.12 UND 7.1.12 vom selben Hersteller aufweist (oder Versionen vor 14.6.0 UND nach 14.6.0), müssen sie zwei PINs einrichten. Die beiden PINs (für jede App) sind in keiner Weise miteinander verknüpft (sie müssen also für die jeweilige App geltende App-Schutzrichtlinie einhalten). Daher kann der Benutzer ein und dieselbe PIN nur dann zweimal einrichten, wenn für App A und App B die gleichen Richtlinien (in Bezug auf die PIN) gelten.

Dieses Verhalten gilt speziell für die PIN für iOS/iPadOS-Anwendungen, die mit der Intune-Verwaltung mobiler Apps aktiviert sind. Wenn Anwendungen im Laufe der Zeit höhere Intune SDK-Versionen für iOS/iPadOS annehmen, ist das zweimalige Festlegen einer PIN für Apps desselben Herausgebers weniger entscheidend. Beachten Sie den Hinweis unterhalb eines Beispiels.

Hinweis

Beispiel: Wenn App A mit einer niedrigeren Version als 7.1.12 (oder 14.6.0) und App B mit einer höheren oder gleichen Version wie 7.1.12 (oder 14.6.0) vom selben Herausgeber erstellt wurde, muss der Endbenutzer die PINs für A und B separat einrichten, sofern beide auf einem iOS/iPadOS-Gerät installiert sind.

Wenn eine App C mit SDK-Version 7.1.9 (oder 14.5.0) auf dem Gerät installiert ist, verwendet sie dieselbe PIN wie App A.

Eine App D, die mit 7.1.14 (oder 14.6.2) erstellt wurde, verwendet dieselbe PIN wie App B.

Wenn auf einem Gerät nur App A und C installiert sind, muss eine PIN festgelegt werden. Dasselbe gilt, wenn auf einem Gerät nur App B und D installiert sind.

Verschlüsselung von App-Daten

IT-Administratoren können eine App-Schutzrichtlinie bereitstellen, die erzwingt, dass App-Daten verschlüsselt werden. Im Rahmen einer solchen Richtlinie kann ein IT-Administrator auch angeben, wann die Inhalte verschlüsselt werden.

Intune-Verfahren für die Datenverschlüsselung
Ausführliche Informationen zur Verschlüsselungseinstellung im Rahmen von App-Schutzrichtlinien finden Sie unter Einstellungen für App-Schutzrichtlinien in Microsoft Intune und Einstellungen für App-Schutzrichtlinien für iOS.

Verschlüsselte Daten
Nur Daten, die als „unternehmenseigen“ markiert sind, werden gemäß der vom IT-Administrator eingerichteten App-Schutzrichtlinie verschlüsselt. Daten werden als „unternehmenseigen“ betrachtet, wenn sie von einem Speicherort des Unternehmens stammen. Bei den Office-Apps betrachtet Intune Folgendes als unternehmenseigenen Speicherort:

  • E-Mail (Exchange)
  • Cloudspeicher (OneDrive-App mit einem OneDrive for Business-Konto)

Bei Branchen-Apps, die vom Intune App Wrapping Tool verwaltet werden, werden alle App-Daten als „unternehmenseigen“ betrachtet.

Selektives Zurücksetzen

Löschen von Daten per Remotezugriff
Intune kann App-Daten auf drei verschiedene Arten löschen:

  • Vollständiges Zurücksetzen des Geräts
  • Selektives Zurücksetzen für MDM
  • Selektives Zurücksetzen für MAM

Weitere Informationen zur Remotezurücksetzung der MDM finden Sie unter Entfernen von Geräten durch Zurücksetzen oder Abkoppeln. Weitere Informationen zum selektiven Zurücksetzen mit MAM finden Sie unter the Retire action (Die Aktion „Abkoppeln“) und Zurücksetzen von Unternehmensdaten in Apps.

Beim vollständigen Zurücksetzen des Geräts werden alle Benutzerdaten und -einstellungen vom Gerät entfernt, indem das Gerät auf die werkseitigen Standardeinstellungen zurückgesetzt wird. Das Gerät wird aus Intune entfernt.

Hinweis

Ein vollständiges Zurücksetzen des Geräts und selektives Zurücksetzen für MDM kann nur auf Geräten erreicht werden, die bei der Intune-Verwaltung mobiler Geräte (MDM) registriert sind.

Selektives Zurücksetzen für MDM
Informationen zum Entfernen von Unternehmensdaten finden Sie unter Remove devices – retire (Entfernen von Geräten: Abkoppeln).

Selektives Zurücksetzen für MAM
Durch selektives Zurücksetzen für MAM können Unternehmensanwendungsdaten von einer App entfernt werden. Die Anforderung wird mit Intune initiiert. Informationen zum Initiieren einer Zurücksetzungsanforderung finden Sie unter So setzen Sie nur die Unternehmensdaten in einer App zurück.

Wenn das selektive Zurücksetzen initiiert wird, während ein Benutzer die App verwendet, überprüft das Intune SDK alle 30 Minuten, ob eine Anforderung zum selektiven Zurücksetzen vom Intune MAM-Dienst vorhanden ist. Das SDK überprüft auch, ob eine Anforderung zum selektiven Zurücksetzen vorhanden ist, wenn ein Benutzer eine App zum ersten Mal startet und sich mit einem Geschäfts-, Uni- oder Schulkonto anmeldet.

Wenn lokale Dienste nicht mit von Intune geschützten Apps funktionieren
Der Intune-App-Schutz hängt davon ab, dass die Identität des Benutzers in der App und im Intune SDK konsistent ist. Die einzige Möglichkeit, dies zu garantieren, ist eine moderne Authentifizierung. Es gibt Szenarien, in denen Apps möglicherweise mit einer lokalen Konfiguration funktionieren. Dies ist aber weder konsistent noch garantiert.

Eine sichere Möglichkeit zum Öffnen von Weblinks in verwalteten Apps
Ein IT-Administrator kann eine App-Schutzrichtlinie für Microsoft Edge bereitstellen und festlegen. Dieser Webbrowser kann problemlos mit Intune verwaltet werden. Der IT-Administrator kann erzwingen, dass alle Weblinks in über Intune verwalteten Apps mit einem verwalteten Browser geöffnet werden müssen.

App-Schutzfunktionen für iOS-Geräte

Erkennung von Fingerabdrücken oder Gesichtern auf dem Gerät

Die Richtlinien für den Intune-App-Schutz ermöglichen es Ihnen, den App-Zugriff nur auf Benutzer mit Intune-Lizenz zu beschränken. Eine der Möglichkeiten, den Zugriff auf die App zu steuern, besteht darin, Apple Touch ID oder Face ID auf unterstützten Geräten zu erfordern. Intune implementiert ein Verhalten, bei dem Intune den Benutzer bei Änderungen an der biometrischen Datenbank des Geräts zur PIN-Eingabe auffordert, wenn der nächste Wert des Inaktivitätstimeouts erfüllt ist. Zu Änderungen an biometrischen Daten zählen das Hinzufügen oder Entfernen von Fingerabdrücken oder Gesichtern. Wenn der Intune-Benutzer keine PIN festgelegt hat, wird er zu einem Fenster für die Einrichtung einer Intune-PIN weitergeleitet.

Zweck dieses Verfahrens ist es, die Daten Ihrer Organisation innerhalb der App und auf App-Ebene kontinuierlich zu schützen. Dieses Feature ist nur für iOS/iPadOS verfügbar und erfordert, dass das Intune SDK für iOS/iPadOS, Version 9.0.1 oder höher in betreffende Anwendungen integriert wird. Die Integration des SDK ist erforderlich, damit das Verhalten für die Zielanwendungen erzwungen werden kann. Diese Integration erfolgt kontinuierlich und ist abhängig von den jeweiligen Anwendungsteams. Einige Apps, die teilnehmen, sind WXP, Outlook, Managed Browser und Viva Engage.

iOS-Freigabeerweiterung

Mithilfe der iOS/iPadOS-Freigabeerweiterung können Geschäfts-, Schul- oder Unidaten in nicht verwalteten Apps geöffnet werden, auch wenn die Datenübertragungsrichtlinie auf Nur verwaltete Apps oder Keine Apps festgelegt ist. Die Intune-App-Schutzrichtlinie kann die iOS/iPadOS-Freigabeerweiterung nicht steuern, ohne das Gerät zu verwalten. Daher verschlüsselt Intune „unternehmenseigene“ Daten, bevor diese außerhalb der App freigegeben werden. Sie können dieses Verschlüsselungsverhalten überprüfen, indem Sie versuchen, eine „unternehmenseigene“ Datei außerhalb der verwalteten App zu öffnen. Die Datei sollte verschlüsselt sein und außerhalb der verwalteten App nicht geöffnet werden können.

Standardmäßig wird der Zugriff auf nicht autorisierte Anwendungsinhalte durch Intune-App-Schutz-Richtlinien verhindert. Für iOS/iPadOS gibt es Funktionen zum Öffnen bestimmter Inhalte oder Anwendungen mit universellen Links.

Benutzer können die universellen Links einer App deaktivieren, indem sie in Safari zu diesen Links navigieren und auf In neuer Registerkarte öffnen oder Öffnen klicken. Um universelle Links mit Intune-App-Schutzrichtlinien verwenden zu können, ist es wichtig, die universellen Links erneut zu aktivieren. Der Endbenutzer muss in Safari inApp-Namen>öffnen<, nachdem er lange auf einen entsprechenden Link gedrückt hat. Dadurch wird jede zusätzliche geschützte App aufgefordert, alle universellen Links an die geschützte Anwendung auf dem Gerät weiterzuleiten.

Mehrere Zugriffseinstellungen des Intune-App-Schutzes für die gleiche Gruppe von Apps und Benutzern

Intune-App-Schutzrichtlinien für den Zugriff werden in einer bestimmten Reihenfolge auf Endbenutzergeräten angewendet, wenn die Benutzer versuchen, über ihr Unternehmenskonto auf eine App zuzugreifen. In der Regel hat ein Zurücksetzungsvorgang Vorrang vor einem Block. Verwerfbare Warnungen werden erst als letztes berücksichtigt. Im Anschluss an die Einstellung, die dem Benutzer den Zugriff verweigert, wird z. B. eine Einstellung der mindestens erforderlichen iOS/iPadOS-Version angewendet, die den Benutzer auffordert, ein Update des iOS/iPadOS-Betriebssystems auszuführen (wenn dies auf den Benutzer/die App zutrifft). In diesem Szenario konfiguriert der IT-Administrator die Einstellung für die mindestens erforderliche iOS-Version auf Version 11.0.0.0 und die mindestens erforderliche iOS-Version, die nur für Warnungen gilt, auf 11.1.0.0. Gleichzeitig versucht das Gerät, auf dem noch die iOS-Version 10 installiert ist, auf die App zuzugreifen. In Folge dessen wird der Endbenutzer basierend auf restriktiveren Einstellungen für die mindestens erforderliche iOS-Version blockiert und erhält keinen Zugriff.

Wenn verschiedene Arten von Einstellungen verarbeitet werden müssen, haben die Anforderungen hinsichtlich bestimmter Versionen des Intune SDK Vorrang. Erst danach werden Anforderungen berücksichtigt, die eine Version einer App oder eines iOS/iPadOS-Betriebssystems betreffen. Anschließend werden in derselben Reihenfolge mögliche Warnungen für sämtliche Einstellungstypen überprüft. Es wird empfohlen, die Anforderung, die die Intune SDK-Version betrifft, nur unter Anleitung des Intune-Produktteams für grundlegende Blockierungsszenarien zu konfigurieren.

App-Schutzfunktionen für Android-Geräte

Hinweis

App-Schutz-Richtlinien (APP) werden auf in Intune verwalteten dedizierten Android Enterprise-Geräten ohne den Modus "Gemeinsam genutzte Geräte" nicht unterstützt. Auf diesen Geräten ist Unternehmensportal Installation erforderlich, damit eine APP-Blockrichtlinie ohne Auswirkungen auf den Benutzer wirksam wird. App-Schutz Richtlinien werden auf in Intune verwalteten dedizierten Android Enterprise-Geräten mit dem Modus "Gemeinsam genutzte Geräte" sowie auf benutzerlosen AOSP-Geräten unterstützt, die den Modus für gemeinsam genutzte Geräte nutzen.

Microsoft Teams-Android-Geräte

Die Teams-App auf Microsoft Teams Android-Geräten unterstützt APP nicht (empfängt keine Richtlinie über die Unternehmensportal-App). Dies bedeutet, dass Appschutz-Richtlinieneinstellungen nicht auf Microsoft Teams-Android-Geräte angewendet werden. Wenn Sie App-Schutzrichtlinien für diese Geräte konfiguriert haben, sollten Sie eine Gruppe von Teams-Gerätebenutzern erstellen und diese Gruppe aus den zugehörigen App-Schutzrichtlinien ausschließen. Erwägen Sie außerdem, Ihre Intune-Registrierungsrichtlinie, Richtlinien für bedingten Zugriff und Intune-Compliance-Richtlinien so zu ändern, dass sie über unterstützte Einstellungen verfügen. Wenn Sie Ihre vorhandenen Richtlinien nicht ändern können, müssen Sie (Ausschluss-) Gerätefilter konfigurieren. Überprüfen Sie jede Einstellung anhand der vorhandenen Konfiguration für den bedingten Zugriff und der Intune-Konformitätsrichtlinie, um festzustellen, ob Sie über nicht unterstützte Einstellungen verfügen. Verwandte Informationen finden Sie unter Unterstützte bedingte Zugriffs- und Intune-Gerätekonformitätsrichtlinien für Microsoft Teams-Räume und Teams-Android-Geräte. Informationen zu Microsoft Teams Rooms finden Sie unter Bedingter Zugriff und Intune-Compliance für Microsoft Teams Rooms.

Biometrische Geräteauthentifizierung

Für Android-Geräte, die die biometrische Authentifizierung unterstützen, können Sie Endbenutzern die Verwendung von Fingerabdruck oder Entsperrung per Gesichtserkennung gestatten, je nachdem, was ihr Android-Gerät unterstützt. Sie können konfigurieren, ob alle biometrischen Typen, die über den Fingerabdruck hinausgehen, zum Authentifizieren verwendet werden können. Beachten Sie, dass die Fingerabdruckauthentifizierung und die Entsperrung per Gesichtserkennung nur für Geräte verfügbar sind, die herstellerbedingt diese biometrischen Typen unterstützen und auf denen die richtige Android-Version ausgeführt wird. Für Fingerabdrücke ist Android 6 erforderlich, für die Entsperrung per Gesichtserkennung ist Android 10 oder höher erforderlich.

Unternehmensportal-App und Intune-App-Schutz

Ein Großteil der App-Schutzfunktionen ist in die Unternehmensportal-App integriert. Eine Registrierung der Geräte ist nicht erforderlich, allerdings wird immer die Unternehmensportal-App benötigt. Bei der Verwaltung mobiler Anwendungen (Mobile Application Management, MAM) muss lediglich die Unternehmensportal-App auf dem Gerät des Endbenutzers installiert sein.

Mehrere Zugriffseinstellungen des Intune-App-Schutzes für die gleiche Gruppe von Apps und Benutzern

Intune-App-Schutzrichtlinien für den Zugriff werden in einer bestimmten Reihenfolge auf Endbenutzergeräten angewendet, wenn die Benutzer versuchen, über ihr Unternehmenskonto auf eine App zuzugreifen. Im Allgemeinen hat ein -Block Vorrang und dann eine abweisendbare Warnung. Es wird z. B. eine Einstellung der mindestens erforderlichen Android-Patch-Version, die den Benutzer auffordert, ein Patchupgrade auszuführen, im Anschluss an die Einstellung angewendet, die dem Benutzer den Zugriff verweigert (wenn dies auf den Benutzer/die App zutrifft). In diesem Szenario konfiguriert der IT-Administrator die Einstellung für die mindestens erforderliche Version des Android-Patch auf den 1.3.2018 und die für die mindestens erforderliche Version des Android-Patch, die nur für Warnungen gilt, auf den 1.2.2018. Gleichzeitig versucht das Gerät, das noch die Patch-Version vom 1.1.2018 verwendet, auf die App zuzugreifen. In Folge dessen wird der Endbenutzer basierend auf restriktiveren Einstellungen für die mindestens erforderliche Version des Android-Patch blockiert und erhält keinen Zugriff.

Bei verschiedenen Einstellungstypen hätte eine App-Versionsanforderung Vorrang, gefolgt von einer Anforderung der Android-Betriebssystemversion und einer Android-Patchversionsanforderung. Anschließend werden alle Warnungen auf alle Arten von Einstellungen in derselben Reihenfolge überprüft.

Intune-App-Schutzrichtlinien und Die Google Play-Geräteintegritätsprüfung für Android-Geräte

Intune-App-Schutzrichtlinien bieten Administratoren die Möglichkeit, Endbenutzergeräte anzufordern, die Google Play-Geräteintegritätsprüfung für Android-Geräte zu bestehen. Eine neue Google Play-Dienstbestimmung wird in einem von Intune festgelegten Intervall an den IT-Administrator gesendet. Die Anzahl der Dienstaufrufe wird in Abhängigkeit von der Last gedrosselt; dieser Wert wird also intern verwaltet und kann nicht konfiguriert werden. Jede vom IT-Administrator konfigurierte Aktion für die Google-Geräteintegritätseinstellung wird basierend auf dem letzten an den Intune-Dienst gemeldeten Ergebnis zum Zeitpunkt des bedingten Starts ausgeführt. Wenn keine Daten vorhanden sind, wird der Zugriff abhängig davon gewährt, dass keine anderen Überprüfungen für den bedingten Start fehlschlagen, und der „Roundtrip“ des Google Play-Diensts zur Bestimmung der Nachweisergebnisse im Back-End startet. Wenn es beim Gerät zu Problemen kommt, wird der Benutzer asynchron benachrichtigt. Wenn die Daten veraltet sind, wird der Zugriff auf Grundlage des zuletzt gemeldeten Ergebnisses blockiert oder gewährt, und ein „Roundtrip“ des Google Play-Diensts zur Bestimmung der Nachweisergebnisse startet. Wenn es beim Gerät zu Problemen kommt, wird der Benutzer asynchron benachrichtigt.

Intune-App-Schutzrichtlinien und die Verify Apps-API von Google für Android-Geräte

Administratoren können in Intune-App-Schutzrichtlinien festlegen, dass Endbenutzergeräte Signale über die Verify Apps-API von Google für Android-Geräte senden müssen. Die dafür erforderlichen Schritte unterscheiden sich leicht je nach Gerät. Der allgemeine Prozess umfasst den Zugriff auf den Google Play Store, klicken Sie dann auf Meine Apps & Spiele, klicken Sie auf das Ergebnis der letzten App-Überprüfung, die Sie zum Play Protect-Menü führt. Sorgen Sie dafür, dass die Option Scan device for security threats (Gerät auf Sicherheitsbedrohungen überprüfen) aktiviert ist.

Googles Play-Integritäts-API

Intune nutzt die Play-Integritäts-APIs von Google, um unsere vorhandenen Stammerkennungsprüfungen für nicht registrierte Geräte hinzuzufügen. Google hat diese APIs für Android-Apps entwickelt und verwaltet sie, wenn die Apps nicht auf gerooteten Geräten ausgeführt werden sollen. Sie kommen z. B. bei der Google Pay-App zum Einsatz. Google stellt zwar nicht alle Überprüfungen, die durchgeführt werden, um Rooting zu erkennen, öffentlich zur Verfügung; wir gehen jedoch davon aus, dass diese APIs Benutzer identifizieren können, die ihr Gerät gerootet haben. Diesen Benutzern kann der Zugriff dann verwehrt werden, oder ihre Unternehmenskonten können aus den Apps entfernt werden, für die Richtlinien aktiviert sind. Die Option Check basic integrity (Grundlegende Integrität überprüfen) informiert Sie über die allgemeine Integrität des Geräts. Für gerootete Geräte, Emulatoren, virtuelle Geräte und Geräte, die Anzeichen von Manipulationen aufweisen, schlägt die Überprüfung der grundlegenden Integrität fehl. Die Option Check basic integrity & certified devices (Grundlegende Integrität und zertifizierte Geräte überprüfen) informiert Sie über die Kompatibilität des Geräts mit Google-Diensten. Nur unveränderte Geräte, die von Google zertifiziert wurden, bestehen diese Überprüfung. Die folgenden Geräte bestehen die Überprüfung nicht:

  • Geräte, für die die Überprüfung der Basisintegrität fehlschlägt
  • Geräte mit entsperrtem Bootloader
  • Geräte mit einem benutzerdefinierten Systemimage/ROM
  • Geräte, für die der Hersteller entweder keine Google-Zertifizierung beantragt hat, oder für die diese nicht bestanden wurde
  • Geräte mit einem Systemimage, das direkt aus den Quelldateien des Open Source-Programms für Android erstellt wurde
  • Geräte mit einem Systemimage, das sich noch in der Betaversion oder in der Entwicklervorschau befindet

Technische Details finden Sie in der Google-Dokumentation zur Play-Integritäts-API von Google .

Einstellung "Integritätsbewertung wiedergeben" und "Geräte mit Jailbreak/Rootzugriff"

Die Wiedergabeintegritätsbewertung erfordert, dass der Endbenutzer online ist, zumindest für den Zeitraum, in dem der "Roundtrip" zum Bestimmen der Nachweisergebnisse ausgeführt wird. Wenn der Endbenutzer offline ist, kann der IT-Administrator immer noch davon ausgehen, dass ein Ergebnis der Einstellung Geräte mit Jailbreak/entfernten Nutzungsbeschränkungen erzwungen wird. Hierbei kommt der Wert Offlinetoleranzperiode ins Spiel, wenn der Endbenutzer zu lange offline war: Sobald dieser Wert erreicht ist, wird der Zugriff auf Geschäfts-, Schul- und Unidaten solange blockiert, bis wieder Netzwerkzugriff besteht. Durch Aktivieren beider Einstellungen können Sie die Integrität von Endbenutzergeräten auf mehreren Ebenen gewährleisten – ein wichtiger Aspekt, wenn Endbenutzer über Mobilgeräte auf Geschäfts-, Schul- und Unidaten zugreifen.

Google Play Protect-APIs und Google Play Services

Die App-Schutzrichtlinieneinstellungen, die Google Play Protect-APIs verwenden, erfordern funktionierende Google Play Services. Sowohl die Bewertung der Play-Integrität als auch die Bedrohungsüberprüfung für Apps erfordern, dass die von Google ermittelte Version der Google Play-Dienste ordnungsgemäß funktioniert. Da diese Einstellungen in den Sicherheitsbereich fallen, werden die Endbenutzer blockiert, für die diese Einstellungen gelten, wenn diese nicht die entsprechende Version von Google Play Services verwenden oder keinen Zugriff auf Google Play Services haben.

Vorschau: App-Schutz Erfahrung für Windows-Geräte

Es gibt zwei Kategorien von Richtlinieneinstellungen: Datenschutz und Integritätsprüfungen. Der Begriff richtlinienverwaltete App bezieht sich auf Apps, die mit App-Schutzrichtlinien konfiguriert sind.

Datenschutz

Die Datenschutzeinstellungen wirken sich auf die Organisationsdaten und den Kontext aus. Als Administrator können Sie die Verschiebung von Daten in und aus dem Kontext des Organisationsschutzes steuern. Der Organisationskontext wird durch Dokumente, Dienste und Websites definiert, auf die über das angegebene Organisationskonto zugegriffen wird. Die folgenden Richtlinieneinstellungen helfen beim Steuern externer Daten, die in den Organisationskontext empfangen werden, und Organisationsdaten, die aus dem Organisationskontext gesendet werden.

Integritätsprüfungen

Mit Integritätsprüfungen können Sie Funktionen für bedingten Start konfigurieren. Dazu müssen Sie die Integritätsprüfungsbedingungen für Ihre App-Schutzrichtlinie festlegen. Wählen Sie eine Einstellung aus, und geben Sie den Wert ein, den Benutzer für den Zugriff auf Ihre Organisationsdaten erfüllen müssen. Wählen Sie dann die Aktion aus, die Sie ausführen möchten, wenn Benutzer Ihre Bedingungen nicht erfüllen. In einigen Fällen können mehrere Aktionen für eine einzelne Einstellung konfiguriert werden.

Nächste Schritte

Erstellen und Bereitstellen von App-Schutzrichtlinien mit Microsoft Intune

Verfügbare Einstellungen für Schutzrichtlinien für Android-Apps mit Microsoft Intune

Einstellungen für App-Schutzrichtlinien für iOS