Häufig gestellte Fragen zu MAM und App-Schutz

ÜBERSICHT ÜBER MAM

App-Schutzrichtlinien sind Regeln, die sicherstellen, dass die Daten einer Organisation in einer verwalteten App jederzeit sicher sind und dort verbleiben. 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.

Ausführliche Informationen zu den einzelnen Einstellungen für App-Schutzrichtlinien finden Sie unter Einstellungen für Android-App-Schutzrichtlinie und iOS/iPadOS-App-Schutzrichtlinien .

Wenn Sie eine MAM-Richtlinie auf den Benutzer anwenden, ohne den Geräteverwaltungsstatus festzulegen, erhält der Benutzer die MAM-Richtlinie sowohl auf dem BYOD-Gerät als auch auf dem Intune verwalteten Gerät. Sie können auch eine MAM-Richtlinie basierend auf dem Geräteverwaltungsstatus anwenden. Wenn Sie also eine App-Schutzrichtlinie erstellen, wählen Sie neben Ziel für Apps auf allen Gerätetypen 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 ebenso strenge MAM-Richtlinie auf Intune verwaltete Geräte wie auf von Drittanbietern verwaltete Geräte an.
• Wenden Sie eine MAM-Richtlinie nur auf nicht registrierte Geräte an.

Weitere Informationen finden Sie unter Überwachen von App-Schutzrichtlinien.

Jede App, die in das Intune App SDK integriert oder vom Intune App Wrapping Tool umschlossen wurde, kann mithilfe Intune App-Schutzrichtlinien verwaltet werden. Sehen Sie sich diesbezüglich die Liste der mit Intune verwalteten Apps an, die für die öffentliche Nutzung verfügbar sind.

• Der Endbenutzer muss über ein Microsoft Entra-Konto verfügen. Informationen zum Erstellen von Intune Benutzern in Microsoft Entra ID finden Sie unter Hinzufügen von Benutzern und Erteilen von Administratorberechtigungen für Intune.

• Der Endbenutzer muss über eine Lizenz für Microsoft Intune verfügen, die dem Microsoft Entra-Konto zugewiesen ist. Informationen zum Zuweisen von Intune-Lizenzen zu Endbenutzern finden Sie unter Verwalten von Intune-Lizenzen.

• Der Endbenutzer muss einer Sicherheitsgruppe angehören, für die eine App-Schutzrichtlinie vorgesehen ist. Die selbe App-Schutzrichtlinie muss auf die App angewendet werden, die verwendet werden soll. App-Schutz Richtlinien können im Microsoft Intune Admin Center erstellt und bereitgestellt werden. Sicherheitsgruppen können zurzeit im Microsoft 365 Admin Center erstellt werden.

• Der Endbenutzer muss sich mit dem Microsoft Entra-Konto bei der App anmelden.

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 mit Intune SDK-Integration mit anderen Plattformen wie React Native und NativeScript erfolgreich waren, bieten wir keine expliziten Anleitungen oder Plug-Ins für App-Entwickler, die etwas anderes als unsere unterstützten Plattformen verwenden.

Das Intune App SDK kann die Microsoft-Authentifizierungsbibliothek für Authentifizierungs- und bedingte Startszenarien verwenden. Außerdem wird msal verwendet, um die Benutzeridentität beim MAM-Dienst für die Verwaltung ohne Geräteregistrierungsszenarien zu registrieren.

• Der Endbenutzer muss die mobile Outlook-App auf dem Gerät installiert haben.

• 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 Intune App-Schutz für Microsoft Exchange Online und Exchange Server mit moderner Hybridauthentifizierung und unterstützt Exchange in Office 365 Dedicated nicht.

• 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 der verwaltete Speicherort beispielsweise OneDrive ist, sollte die OneDrive-App in der Word,Excel- oder PowerPoint-App des Endbenutzers 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.

Intune markiert alle Daten in der App entweder als "unternehmensintern" oder "persönlich". Daten werden als "Unternehmensdaten" betrachtet, wenn sie von einem Geschäftsstandort stammen. Bei den Office-Apps betrachtet Intune Folgendes als Unternehmensspeicher: E-Mail-Speicher (Exchange) oder Cloudspeicher (OneDrive-App mit einem OneDrive for Business-Konto).

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 for SfB on-premises mit Microsoft Entra ID.

Unterstützung für mehrere Identitäten ist die Möglichkeit, dass das Intune App SDK nur App-Schutzrichtlinien auf das bei der App angemeldete Geschäfts-, Schul- oder Unikonto anwendet. Wenn ein persönliches Konto bei der App angemeldet ist, kann nicht auf die Daten zugegriffen werden.

Die Unterstützung mehrerer Identitäten ermöglicht die öffentliche Veröffentlichung von Apps mit "Unternehmens- und Consumerzielgruppen" (d. h. den Office-Apps) mit Intune App-Schutzfunktionen für die "Unternehmenskonten".

Da Outlook über eine kombinierte E-Mail-Ansicht von persönlichen und "unternehmenseigenen" E-Mails verfügt, fordert die Outlook-App beim Start zur eingabe der Intune-PIN auf.

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.

Intune fordert den Benutzer zur Eingabe seiner App-PIN auf, wenn dieser versucht, auf „unternehmenseigene“ Daten zuzugreifen. In Apps mit mehreren Identitäten wie Word/Excel/PowerPoint wird der Benutzer zur Eingabe seiner PIN aufgefordert, wenn er versucht, ein "Unternehmensdokument oder eine Unternehmensdatei" zu öffnen. In Apps mit nur einer Identität, z. B. branchenspezifischen Apps, die mit dem Intune App Wrapping Tool verwaltet werden, wird die PIN beim Start aufgefordert, da das Intune App SDK weiß, dass die Benutzerfreundlichkeit in der App immer "unternehmensintern" ist.

Der IT-Administrator kann die Intune App-Schutzrichtlinieneinstellung "Erneut überprüfen der Zugriffsanforderungen nach (Minuten)" im Microsoft Intune Admin Center definieren. Diese Einstellung gibt an, wie lange die Zugriffsanforderungen auf dem Gerät überprüft werden und der PIN-Bildschirm der Anwendung erneut angezeigt wird. Folgende Faktoren beeinflussen, wie häufig ein Benutzer zur PIN-Eingabe aufgefordert wird:

• Die PIN wird von Apps desselben Herausgebers gemeinsam genutzt, um die Benutzerfreundlichkeit zu verbessern: Unter iOS/iPadOS wird eine App-PIN für alle Apps desselben App-Herausgebers freigegeben. Unter Android wird eine App-PIN für alle Apps genutzt.
• Das Verhalten "Zugriffsanforderungen nach (Minuten) erneut überprüfen" nach einem Geräteneustart: Ein "PIN-Timer" verfolgt die Anzahl der Minuten der Inaktivität nach, die bestimmen, wann die Intune App-PIN als Nächstes angezeigt werden soll. Unter iOS/iPadOS ist der PIN-Timer vom Neustart des Geräts nicht betroffen. Daher hat der Neustart des Geräts keine Auswirkungen auf die Anzahl der Minuten, in denen der Benutzer inaktiv war, in einer iOS-/iPadOS-App mit Intune PIN-Richtlinie. Unter Android wird der PIN-Timer beim Neustart des Geräts zurückgesetzt. Daher werden Android-Apps mit Intune PIN-Richtlinie wahrscheinlich unabhängig vom Einstellungswert "Zugriffsanforderungen nach (Minuten)" nach einem Geräteneustart zur Eingabe einer App-PIN aufgefordert.
• Die rollierende Natur des Timers, der der PIN zugeordnet ist: Sobald eine PIN für den Zugriff auf eine App (App A) eingegeben wurde und die App den Vordergrund (Standard Eingabefokus) auf dem Gerät verlässt, wird der PIN-Timer für diese PIN zurückgesetzt. Jede App (App B), die diese PIN teilt, fordert den Benutzer nicht zur PIN-Eingabe auf, da der Timer zurückgesetzt wurde. Die Aufforderung wird wieder angezeigt, wenn der Wert für „Zugriffsanforderungen nach (Minuten) erneut überprüfen“ erneut erreicht wurde.

Bei iOS-/iPadOS-Geräten wird die Eingabeaufforderung erneut angezeigt, selbst wenn die PIN von Apps verschiedener Herausgeber gemeinsam genutzt wird, wenn der Wert Zugriffsanforderungen nach (Minuten) erneut überprüfen für die App erfüllt wird, die nicht der Standard Eingabefokus ist. 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.

Die Intune PIN funktioniert basierend auf einem inaktivitätsbasierten Timer (der 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.

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 App 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 bezieht sich nicht auf die App-PIN, sondern ist eine eigene App-Schutzrichtlinie.

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 Anzahl der Versuche erfüllt wurde, kann das Intune App SDK die "Unternehmensdaten" in der App zurücksetzen.

MAM (unter iOS/iPadOS) ermöglicht derzeit eine PIN auf Anwendungsebene mit alphanumerischen und Sonderzeichen (als "Passcode" bezeichnet), die die Teilnahme von Anwendungen (z. B. WXP, Outlook, Managed Browser, Yammer) erfordert, um das Intune APP SDK für iOS/iPadOS zu integrieren. Ohne dies werden die Kennungseinstellungen für die Zielanwendungen nicht ordnungsgemäß erzwungen. Dies war ein Feature, das im Intune SDK für iOS/iPadOS 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. Wenn ein Gerät also über Anwendungen mit Intune SDK für iOS/iPadOS-Versionen vor 7.1.12 und nach 7.1.12 desselben Herausgebers verfügt, müssen zwei PINs eingerichtet werden.

Abgesehen davon sind die beiden PINs (für jede App) in keiner Weise verknüpft, d. h. sie müssen der App-Schutzrichtlinie entsprechen, die auf die App angewendet wird. 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.

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.

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.

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 Unternehmensspeicher: E-Mail-Speicher (Exchange) oder Cloudspeicher (OneDrive-App mit einem OneDrive for Business-Konto). Bei branchenspezifischen Apps, die vom Intune App Wrapping Tool verwaltet werden, werden alle App-Daten als "unternehmensintern" betrachtet.

Intune können App-Daten auf drei verschiedene Arten zurücksetzen: vollständiges Zurücksetzen des Geräts, selektives Zurücksetzen für MDM und selektives Zurücksetzen von 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.

Durch Zurücksetzen werden alle Benutzerdaten und Einstellungen vom Gerät entfernt, indem das Gerät auf die werksseitigen Standardeinstellungen zurückgesetzt wird. Das Gerät wird aus Intune entfernt.

Informationen zum Entfernen von Unternehmensdaten finden Sie unter Remove devices – retire (Entfernen von Geräten: Abkoppeln).

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

Wenn der Benutzer die App verwendet, wenn das selektive Zurücksetzen initiiert wird, überprüft das Intune App SDK alle 30 Minuten eine selektive Zurücksetzungsanforderung vom Intune MAM-Dienst. 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.

Intune App-Schutz hängt von der Identität des Benutzers ab, um zwischen der Anwendung und dem Intune App SDK konsistent zu sein. Die einzige Möglichkeit, dies zu garantieren, ist eine moderne Authentifizierung. Es gibt Szenarien, in denen Apps möglicherweise mit einer lokalen Konfiguration funktionieren, aber weder konsistent noch garantiert sind.

Ja! Der IT-Administrator kann eine App-Schutzrichtlinie für die Microsoft Edge-App bereitstellen und festlegen. Der IT-Administrator kann verlangen, dass alle Weblinks in Intune verwalteten Apps mit der Microsoft Edge-App geöffnet werden.

Unternehmensportal-App und Intune-App-Schutz

Intune App-Schutzrichtlinien für den Zugriff werden in einer bestimmten Reihenfolge auf Endbenutzergeräten angewendet, wenn sie versuchen, über ihr Unternehmenskonto auf eine Ziel-App zuzugreifen. Im Allgemeinen würde ein -Block Vorrang haben 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.

Wenn verschiedene Arten von Einstellungen verarbeitet werden müssen, haben die Anforderungen hinsichtlich bestimmter App-Versionen Vorrang. Erst danach werden Anforderungen berücksichtigt, die eine Version des Android-Betriebssystems und Android-Patch-Versionen betreffen. Anschließend werden in derselben Reihenfolge mögliche Warnungen für sämtliche Einstellungstypen überprüft.

Der Intune-Dienst kontaktiert Google Play in einem nicht konfigurierbaren Intervall, das durch die Dienstauslastung bestimmt wird. Jede aktion, die vom IT-Administrator für die Einstellung zur Überprüfung der Geräteintegrität von Google Play konfiguriert wurde, wird basierend auf dem letzten an den Intune Dienst gemeldeten Ergebnis zum Zeitpunkt des bedingten Starts ausgeführt. Wenn das Ergebnis der Geräteintegrität von Google konform ist, wird keine Aktion ausgeführt. Wenn das Ergebnis der Geräteintegrität von Google nicht konform ist, wird die vom IT-Administrator konfigurierte Aktion sofort ausgeführt. Wenn die Anforderung an die Geräteintegritätsprüfung von Google Play aus irgendeinem Grund fehlschlägt, wird das zwischengespeicherte Ergebnis der vorherigen Anforderung bis zu 24 Stunden lang oder beim nächsten Geräteneustart verwendet, der immer zuerst eintritt. Zu diesem Zeitpunkt blockieren Intune App-Schutzrichtlinien den Zugriff, bis ein aktuelles Ergebnis abgerufen werden kann.

Die Anweisungen dazu variieren je nach Gerät geringfügig. Grundsätzlich müssen Sie dafür den Google Play Store besuchen, dort auf My apps & games (Meine Apps und Spiele) klicken und dann auf das Ergebnis der letzten App-Überprüfung klicken. Dadurch gelangen Sie zum Play Protect-Menü. Sorgen Sie dafür, dass die Option Scan device for security threats (Gerät auf Sicherheitsbedrohungen überprüfen) aktiviert ist.

Intune nutzt Google Play-Integritäts-APIs, um unsere vorhandenen Stammerkennungsprüfungen für nicht registrierte Geräte hinzuzufügen. Google hat diesen API-Satz für Android-Apps entwickelt und verwaltet, die übernommen werden können, wenn ihre Apps nicht auf Geräten mit Root-Basis ausgeführt werden sollen. Sie kommen z. B. bei der Google Pay-App zum Einsatz. Google gibt zwar nicht die gesamte Stammerkennungsüberprüfung öffentlich frei, aber wir erwarten, dass diese APIs Benutzer erkennen, die ihre Geräte 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. "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. "Grundlegende Integrität & zertifizierten Geräten überprüfen" informiert Sie über die Kompatibilität des Geräts mit den Diensten von Google. 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 Integrity-API .

Google Play-Integritäts-API-Überprüfungen erfordern, 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 weiterhin erwarten, dass ein Ergebnis von der Einstellung "Geräte mit Jailbreak/Rootzugriff" erzwungen wird. Wenn der Endbenutzer jedoch zu lange offline war, kommt der Wert "Offline-Toleranzperiode" ins Spiel, und der gesamte Zugriff auf Geschäfts-, Schul- oder Unidaten wird blockiert, sobald dieser Zeitgeberwert erreicht ist, bis der Netzwerkzugriff verfügbar ist. Das Aktivieren beider Einstellungen ermöglicht einen mehrstufigen Ansatz, um die Integrität von Endbenutzergeräten zu gewährleisten, was wichtig ist, wenn Endbenutzer auf Geschäfts-, Schul- oder Unidaten auf mobilgeräten zugreifen.

Sowohl die Einstellungen "Play-Integritätsbewertung" als auch "Bedrohungsüberprüfung für Apps" erfordern, dass die von Google ermittelte Version der Google Play-Dienste ordnungsgemäß funktioniert. Da es sich um Einstellungen handelt, die in den Sicherheitsbereich fallen, wird der Endbenutzer blockiert, wenn er diese Einstellungen verwendet hat und nicht die entsprechende Version von Google Play Services erfüllt oder keinen Zugriff auf Google Play Services hat.

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 bei Einer Änderung an der biometrischen Datenbank des Geräts Intune den Benutzer zur Eingabe einer PIN auffordert, wenn der nächste Inaktivitätstimeoutwert erreicht wird. 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 aufgefordert, eine Intune PIN einzurichten.

Dadurch sollen die Daten Ihrer organization innerhalb der App weiterhin geschützt und auf App-Ebene geschützt bleiben. Dieses Feature ist nur für iOS/iPadOS verfügbar und erfordert die Teilnahme von Anwendungen, die das Intune APP SDK für iOS/iPadOS, Version 9.0.1 oder höher, integrieren. 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. Zu den betreffenden Apps zählen z. B. WXP, Outlook, Managed Browser und Yammer.

Intune App-Schutzrichtlinie kann die iOS-Freigabeerweiterung nicht steuern, ohne das Gerät zu verwalten. Daher verschlüsselt Intune "Unternehmensdaten", bevor sie außerhalb der App freigegeben werden. Sie können dies überprüfen, indem Sie versuchen, die "Unternehmensdatei" 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.

Intune App-Schutzrichtlinien für den Zugriff werden in einer bestimmten Reihenfolge auf Endbenutzergeräten angewendet, wenn sie versuchen, über ihr Unternehmenskonto auf eine Ziel-App zuzugreifen. Im Allgemeinen hat ein Zurücksetzen Vorrang, gefolgt von einem -Block und dann einer abweisenden Warnung. 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 dem Szenario also, in dem der IT-Administrator das Mindestbetriebssystem iOS/iPadOS auf 11.0.0.0 und das mindeste iOS/iPadOS-Betriebssystem (nur Warnung) auf 11.1.0.0 konfiguriert, Während das Gerät, das versucht, auf die App zuzugreifen, unter iOS/iPadOS 10 war, würde der Endbenutzer basierend auf der restriktiveren Einstellung für die mindeste iOS/iPadOS-Betriebssystemversion blockiert, was zu blockiertem Zugriff führt.

Bei verschiedenen Einstellungstypen würde eine Intune App SDK-Versionsanforderung Vorrang haben, und dann eine App-Versionsanforderung, gefolgt von der Anforderung der iOS-/iPadOS-Betriebssystemversion. Anschließend werden in derselben Reihenfolge mögliche Warnungen für sämtliche Einstellungstypen überprüft. Es wird empfohlen, die Intune App SDK-Versionsanforderung nur nach Anleitung des Intune Produktteams für wichtige Blockierungsszenarien zu konfigurieren.

Siehe auch

• Bereitstellen von Intune
• Erstellen eines Rolloutplans
• Verwaltungsrichtlinieneinstellungen für mobile Android-Apps in Microsoft Intune
• Richtlinieneinstellungen für die Verwaltung mobiler iOS-/iPadOS-Apps
• App-Schutz Richtlinienaktualisierung
• Überprüfen Ihrer App-Schutzrichtlinien
• Hinzufügen von App-Konfigurationsrichtlinien für verwaltete Apps ohne Geräteregistrierung
• So erhalten Sie Support in Microsoft Intune