Diese Seite wurde von der Cloud Translation API übersetzt.

Sicherheit

Mit den Funktionen in diesem Leitfaden werden Funktionen zur Sicherheitsverwaltung beschrieben, die Sie in Ihrer Device Policy Controller-App (DPC) implementieren können. Dieses Dokument enthält Codebeispiele. Sie können die App DPC testen auch als Quellcode für Beispielcode für die Unternehmensfunktionen von Android verwenden.

Eine DPC-App kann auf privaten Geräten im Profilinhabermodus oder auf vollständig verwalteten Geräten im Geräteinhabermodus ausgeführt werden. In der folgenden Tabelle sind die Funktionen aufgeführt, die verfügbar sind, wenn der DPC im Profilinhabermodus oder Geräteinhabermodus ausgeführt wird:

Funktion	Profilinhaber	Geräteinhaber
Zugriff auf Apps deaktivieren	✓	✓
Apps aus unbekannten Quellen blockieren	✓	✓
Konten bei Google Play einschränken	✓	✓
Schutz für zurückgesetzte Geräte aktivieren		✓
Überwachungsprotokolle für Unternehmen und Fehlerberichte per Fernzugriff		✓
Auf ein Clientzertifikat Zugriff gewähren und Zugriff entfernen	✓	✓
Sichere Sicherheitscodes zurücksetzen	✓	✓
Sicherheitsherausforderung des Arbeitsprofils	✓

Zugriff auf Apps deaktivieren

Für Organisationen, die zu bestimmten Tageszeiten oder an bestimmten Wochentagen verhindern möchten, dass Mitarbeiter Spiele spielen oder YouTube-Videos auf ihrem Android-Gerät ansehen, kann ein DPC den Zugriff auf Apps vorübergehend deaktivieren.

Zum Deaktivieren des Zugriffs auf Apps wird setPackagesSuspended() von einem DPC konfiguriert, der im Modus „Geräteinhaber“ oder „Profilinhaber“ ausgeführt wird. Die ausgewählte App verhält sich dann so, als wäre sie deaktiviert. Im Google Launcher wird die App ausgegraut. Wenn ein Nutzer auf die App tippt, erscheint ein Systemdialog mit dem Hinweis, dass die App gesperrt ist.

Solange eine App gesperrt ist, kann sie keine Aktivitäten starten und Benachrichtigungen an das Paket werden unterdrückt. Gesperrte Pakete werden nicht auf dem Übersichtsbildschirm angezeigt. Außerdem können keine Dialogfelder (einschließlich Toasts und Snackbars) angezeigt werden und das Gerät kann weder Ton wiedergegeben noch vibrieren.

Launcher können feststellen, ob eine App gesperrt wurde, indem sie die Methode isPackageSuspended() aufrufen. Weitere Informationen zum Konfigurieren der App-Sperrung finden Sie unter setPackagesSuspended.

Apps aus unbekannten Quellen blockieren

Apps, die nicht über Google Play oder andere vertrauenswürdige App-Shops installiert wurden, werden als Apps aus unbekannten Quellen bezeichnet. Bei der Installation dieser Apps ist das Geräte- und Datenrisiko höher.

Um zu verhindern, dass jemand Apps aus unbekannten Quellen installiert, können Administratorkomponenten von vollständig verwalteten Geräten und Arbeitsprofilen die Nutzereinschränkung DISALLOW_INSTALL_UNKNOWN_SOURCES hinzufügen.

Geräteweite Beschränkung des Arbeitsprofils

Wenn der Administrator eines Arbeitsprofils DISALLOW_INSTALL_UNKNOWN_SOURCES hinzufügt, gilt die Einschränkung nur für das Arbeitsprofil. Der Administrator eines Arbeitsprofils kann jedoch eine geräteübergreifende Einschränkung vornehmen, indem er eine verwaltete Konfiguration für Google Play festlegt. Die geräteübergreifende Einschränkung ist ab Android 8.0 verfügbar, wenn die Google Play App Version 80812500 oder höher installiert ist.

So beschränken Sie App-Installationen auf Google Play:

Legen Sie ein verwaltetes Konfigurationspaket für das Google Play-Paket com.android.vending fest.
Geben Sie im Bundle einen booleschen Wert für den Schlüssel verify_apps:device_wide_unknown_source_block ein.
Fügen Sie die Nutzereinschränkung ENSURE_VERIFY_APPS hinzu.

Das folgende Beispiel zeigt, wie du prüfen kannst, ob Google Play diese Einstellung unterstützt, und den Wert auf true festlegen:

Kotlin

internal val DEVICE_WIDE_UNKNOWN_SOURCES = "verify_apps:device_wide_unknown_source_block"
internal val GOOGLE_PLAY_APK = "com.android.vending"

// ...

// Add the setting to Google Play's existing managed config. Supported in
// Google Play version 80812500 or higher--older versions ignore unsupported
// settings.
val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
var existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putBoolean(DEVICE_WIDE_UNKNOWN_SOURCES, true)
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig)

// Make sure that Google Play Protect verifies apps.
dpm.addUserRestriction(adminName, UserManager.ENSURE_VERIFY_APPS)
dpm.addUserRestriction(adminName, UserManager.DISALLOW_INSTALL_UNKNOWN_SOURCES)

Java

static final String DEVICE_WIDE_UNKNOWN_SOURCES =
    "verify_apps:device_wide_unknown_source_block";
static final String GOOGLE_PLAY_APK = "com.android.vending";

// ...


// Add the setting to Google Play's existing managed config. Supported in
// Google Play version 80812500 or higher--older versions ignore unsupported
// settings.
DevicePolicyManager dpm =
    (DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE);
Bundle existingConfig =
    dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putBoolean(DEVICE_WIDE_UNKNOWN_SOURCES, true);
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig);

// Make sure that Google Play Protect verifies apps.
dpm.addUserRestriction(adminName, UserManager.ENSURE_VERIFY_APPS);
dpm.addUserRestriction(adminName, UserManager.DISALLOW_INSTALL_UNKNOWN_SOURCES);

Die Benutzeroberfläche in den Systemeinstellungen bleibt aktiv, das System blockiert jedoch die Installation von Anwendungen. Diese Einschränkung betrifft künftige Installationen – zuvor installierte Apps bleiben auf dem Gerät. Gerätenutzer können mit Android Debug Bridge (ADB) weiterhin Apps im privaten Profil installieren.

Weitere Informationen zu unbekannten Quellen finden Sie unter Alternative Verteilungsoptionen.

Konten bei Google Play einschränken

Manchmal möchte eine Organisation Nutzern erlauben, private Google-Konten hinzuzufügen (z. B. um E-Mails in Gmail zu lesen), möchte aber nicht, dass über das private Konto Apps installiert werden. Ihr DPC kann eine Liste von Konten erstellen, die Nutzer in Google Play verwenden können.

Administratorkomponenten von vollständig verwalteten Geräten oder Arbeitsprofilen können die Konten einschränken, indem sie eine verwaltete Konfiguration für Google Play festlegen. Die Kontoeinschränkung ist verfügbar, wenn die installierte Google Play-App Version 80970100 oder höher ist.

So können Sie die Anzahl der Konten in Google Play einschränken:

Legen Sie ein verwaltetes Konfigurationspaket für das Google Play-Paket com.android.vending fest.
Geben Sie im Bundle die durch Kommas getrennten E-Mail-Adressen als Stringwert für den Schlüssel allowed_accounts ein.

Das folgende Beispiel zeigt, wie Sie Konten einschränken können:

Kotlin

internal val ALLOWED_ACCOUNTS = "allowed_accounts"
internal val GOOGLE_PLAY_APK = "com.android.vending"

// ...

// Limit Google Play to one work and one personal account. Use
// a comma-separated list of account email addresses (usernames).
val googleAccounts = "ali@gmail.com,ali.connors@example.com"

// Supported in Google Play version 80970100 or higher.
val existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putString(ALLOWED_ACCOUNTS, googleAccounts)
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig)

Java

static final String ALLOWED_ACCOUNTS = "allowed_accounts";
static final String GOOGLE_PLAY_APK = "com.android.vending";

// ...


// Limit Google Play to one work and one personal account. Use
// a comma-separated list of account email addresses (usernames).
String googleAccounts = "ali@gmail.com,ali.connors@example.com";

// Supported in Google Play version 80970100 or higher.
Bundle existingConfig =
    dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putString(ALLOWED_ACCOUNTS, googleAccounts);
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig);

Wenn Sie Google Play nur auf das Arbeitskonto beschränken möchten, legen Sie allowed_accounts auf das einzelne verwaltete Konto fest, sobald Ihr DPC die E-Mail-Adresse des Kontos kennt. Ein leerer String verhindert, dass Nutzer ein Konto bei Google Play verwenden können.

Schutz für zurückgesetzte Geräte von Unternehmen aktivieren

Mithilfe des Schutzes für zurückgesetzte Geräte auf Werkseinstellungen können Organisationen angeben, welche Google-Konten ein auf die Werkseinstellungen zurückgesetztes Gerät bereitstellen können.

Der Schutz vor Zurücksetzen auf die Werkseinstellungen durch Kunden wurde entwickelt, um den Diebstahl von Geräten zu verhindern. Bevor das Gerät nach einem nicht autorisierten Zurücksetzen auf die Werkseinstellungen (z. B. mit einem EMM) bereitgestellt werden kann, muss der Nutzer sich im Einrichtungsassistenten bei allen Google-Konten authentifizieren, die sich zuvor auf dem privaten Profil des Geräts befanden.

In einer Unternehmensumgebung ist das Zurücksetzen auf die Werkseinstellungen ein wichtiges Werkzeug, um Mitarbeitergeräte zu verwalten, wenn ein Mitarbeiter die Organisation verlässt. Wenn die Organisation jedoch die Kontoanmeldedaten eines Mitarbeiters nicht kennt, kann der Schutz vor Zurücksetzen auf die Werkseinstellungen verhindern, dass die Organisation ein Gerät an einen anderen Mitarbeiter ausstellen kann.

Bereitstellung nach dem Zurücksetzen auf die Werkseinstellungen steuern

Wenn der DPC im Modus „Geräteeigentümer“ ausgeführt wird, kann er mit setFactoryResetProtectionPolicy() steuern, welche Konten nach dem Zurücksetzen auf die Werkseinstellungen zur Bereitstellung eines Geräts autorisiert sind. Wenn diese Konfiguration auf null oder eine leere Liste festgelegt ist, sind die Konten im persönlichen Profil des Geräts, die nach dem Zurücksetzen auf die Werkseinstellungen berechtigt sind, ein Gerät bereitzustellen.

Ein DPC kann diese Konten während der gesamten Lebensdauer eines vollständig verwalteten Geräts konfigurieren.

Der IT-Administrator kann die Methode people.get der People API mit dem speziellen Wert me verwenden. Dadurch wird der userId für das angemeldete Konto abgerufen. userID wird im resourceName-Schlüssel in der Form people/[userId] als Ganzzahlstring zurückgegeben. Neu erstellte Konten sind möglicherweise 72 Stunden lang nicht für das Zurücksetzen auf die Werkseinstellungen verfügbar.
Sie können auch zulassen, dass ein oder mehrere IT-Administratoren das Gerät nach dem Zurücksetzen auf die Werkseinstellungen entsperren. Jeder dieser IT-Administratoren muss sich in seinem Google-Konto anmelden, Schritt 1 ausführen und seine userId mit Ihnen teilen, damit Sie diese userIds im nächsten Schritt der Liste hinzufügen können.
Der DPC legt mithilfe von setFactoryResetProtectionPolicy() eine geeignete Anwendungseinschränkung fest. Damit wird die Liste der userId festgelegt, die ein auf die Werkseinstellungen zurückgesetztes Gerät bereitstellen können.
Der DPC aktiviert die Konten, die nach dem Zurücksetzen auf die Werkseinstellungen Geräte bereitstellen können. Dazu wird die Broadcast-com.google.android.gms.auth.FRP_CONFIG_CHANGED als explizite Absicht gesendet, um zu verhindern, dass sie aufgrund von Hintergrundbeschränkungen gelöscht werden.

Kotlin

const val ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

// List of userId that can provision a factory reset device.
// You can use the value returned calling people/me endpoint.
val accountIds = listOf("000000000000000000000")

dpm.setFactoryResetProtectionPolicy(
    adminName,
    FactoryResetProtectionPolicy.Builder()
        .setFactoryResetProtectionAccounts(accountIds)
        .setFactoryResetProtectionEnabled(true)
        .build()
)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

// List of userId that can provision a factory reset device.
// You can use the value returned calling people/me endpoint.
List<String> accountIds = new ArrayList<String>();
accountIds.add("000000000000000000000");

dpm.setFactoryResetProtectionPolicy(
    adminName,
    new FactoryResetProtectionPolicy.Builder()
        .setFactoryResetProtectionAccounts(accountIds)
        .setFactoryResetProtectionEnabled(true)
        .build());

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Legacy

Bei Geräten, die das mit API-Level 30 eingeführte setFactoryResetProtectionPolicy() nicht verwenden können, kann Ihr DPC setApplicationRestrictions verwenden, um die ausgewählten Konten der verwalteten factoryResetProtectionAdmin-Konfiguration für das Paket com.google.android.gms hinzuzufügen.

Kotlin

const val GOOGLE_PLAY_APK = "com.android.vending"
const val FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin"
const val DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

val existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, false)
newConfig.putString(FACTORY_RESET_PROTECTION_ADMIN, googleAccounts)
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String GOOGLE_PLAY_APK = "com.android.vending";
static final String FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin";
static final String DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

Bundle existingConfig =
        dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, false);
newConfig.putStringArray(FACTORY_RESET_PROTECTION_ADMIN,
        accountIds.toArray(new String[accountIds.size()]));
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig);

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Schutz vor Zurücksetzen auf Werkseinstellungen durch Unternehmen deaktivieren

Zum Deaktivieren des Schutzes für zurückgesetzte Geräte kann der DPC setFactoryResetProtectionPolicy() verwenden und den Wert null übergeben.

Kotlin

const val ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

dpm.setFactoryResetProtectionPolicy(adminName, null)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

dpm.setFactoryResetProtectionPolicy(adminName, null);

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Legacy

Bei Geräten, die das mit API-Level 30 eingeführte setFactoryResetProtectionPolicy() nicht verwenden können, kann Ihr DPC mit setApplicationRestrictions den Schlüssel/Wert true in der verwalteten Konfiguration disableFactoryResetProtectionAdmin für das Paket com.google.android.gms festlegen.

Kotlin

const val GOOGLE_PLAY_APK = "com.android.vending"
const val FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin"
const val DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

val existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, true)

dpm.setApplicationRestrictions(
    adminName, GOOGLE_PLAY_SERVICES_PACKAGE, restrictions
)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String GOOGLE_PLAY_APK = "com.android.vending";
static final String FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin";
static final String DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

Bundle existingConfig =
        dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, true);

dpm.setApplicationRestrictions(
    adminName, GOOGLE_PLAY_SERVICES_PACKAGE, restrictions);

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Überwachung von Enterprise-Prozessprotokollen und Fehlerberichten per Fernzugriff

In Ihrer EMM-Konsole kann ein Administrator vollständig verwaltete Geräte mithilfe von Unternehmensprozessprotokollen und Remote-Fehlerberichten überwachen.

Aktivitäten auf Unternehmensgeräten protokollieren

Ein DPC, der im Geräteeigentümermodus ausgeführt wird, kann verdächtige Aktivitäten per Remote-Tracking erkennen. Dazu gehören App-Starts, ADB-Aktivitäten (Android Debug Bridge) und Bildschirmentsperrungen. Für Prozessprotokolle ist keine Nutzereinwilligung erforderlich.

Zum Aktivieren oder Deaktivieren des Loggings ruft ein DPC setSecurityLoggingEnabled() auf.

Wenn ein neuer Batch von Logs verfügbar ist, empfängt ein DeviceAdminReceiver den onSecurityLogsAvailable()-Callback. Zum Abrufen der Logs (nach Empfang des Callbacks) ruft ein DPC retrieveSecurityLogs() auf.

DPCs können auch retrievePreRebootSecurityLogs() aufrufen, um Sicherheitslogs abzurufen, die im vorherigen Neustartzyklus generiert wurden. Dies ist das Intervall zwischen dem letzten Geräteneustart und dem vorhergehenden Neustart. Für Geräte, die retrieveSecurityLogs() nicht unterstützen, wird null zurückgegeben. Wenn Ihre Anwendung Logs sowohl mit retrievePreRebootSecurityLogs() als auch mit retrieveSecurityLogs() abruft, müssen Sie nach doppelten Einträgen suchen.
Hinweis: Mit dieser Funktion werden nur Aktivitäten auf vollständig verwalteten Geräten protokolliert, auf denen ein einzelner Nutzer oder verknüpfte Nutzer vorhanden sind. Diese Funktion funktioniert nicht auf privaten Geräten, da sie geräteübergreifende Aktivitäten protokolliert.

Diese Einstellung kann bei der Prüfung nach Sicherheitsereignissen nützlich sein, da sie die folgenden Arten von Aktionen protokolliert:

Jedes Mal, wenn die App neu gestartet wird. So können Sie leichter erkennen, ob die Malware mit einer manipulierten App beginnt.
Fehlgeschlagene Entsperrversuche auf einem Gerät So lässt sich erkennen, ob es innerhalb kurzer Zeit mehrere fehlgeschlagene Entsperrversuche gibt.
Potenziell schädliche ADB-Befehle, wenn ein Nutzer das Gerät über ein USB-Kabel mit einem Computer verbindet.

Weitere Informationen zum Lesen von Protokollen finden Sie unter SecurityLog.

Während Sie entwickeln und testen, können Sie das System zwingen, vorhandene Sicherheitslogs für Ihren DPC verfügbar zu machen. Sie müssen nicht auf einen vollständigen Batch warten. Führen Sie unter Android 9.0 (API-Level 28) oder höher den folgenden Android Debug Bridge-Befehl (adb) in Ihrem Terminal aus:

adb shell dpm force-security-logs

Das System schränkt ein, wie oft du das Tool verwenden kannst, und meldet eine absichtliche Verlangsamung in der Terminalausgabe. Sind Protokolle verfügbar, empfängt der DPC den onSecurityLogsAvailable()-Callback.

Fehlerbericht per Fernzugriff anfordern

Ein DPC, der im Geräteeigentümermodus ausgeführt wird, kann Fehlerberichte für Nutzergeräte mit nur einem Nutzer oder verknüpften Nutzern remote anfordern. Der Fehlerbericht erfasst die Geräteaktivität genau in dem Moment, in dem der Fehlerbericht angefordert wird. Er kann aber auch Aktivitäten der letzten Stunden enthalten, je nachdem, wie oft der Logcat-Zwischenspeicher aktualisiert wird.

Wenn Sie Fehlerberichte per Fernzugriff anfordern möchten, ruft der DPC requestBugreport() auf:

Wenn ein Nutzer das Teilen des Fehlerberichts akzeptiert, erhält der DPC den Fehlerbericht mithilfe von onBugreportShared().
Wenn ein Nutzer das Teilen des Fehlerberichts ablehnt, erhält der DPC mit onBugreportSharingDeclined() eine Meldung über eine abgelehnte Freigabeanfrage.
Wenn der Fehlerbericht fehlschlägt, sieht der DPC onBugreportFailed() mit BUGREPORT_FAILURE_FAILED_COMPLETING oder BUGREPORT_FAILURE_FILE_NO_LONGER_AVAILABLE.

Zugriff auf ein Clientzertifikat gewähren und entfernen

Wenn ein DPC, der im Profilinhaber- oder Geräteinhabermodus ausgeführt wird, einer Drittanbieter-App die Berechtigung zum Verwalten von Zertifikaten gewährt, kann sich die Anwendung ohne Eingriff eines Nutzers Zugriff auf installierte Zertifikate gewähren. Verwenden Sie installKeyPair(), um ein Zertifikat zu installieren, auf das alle Apps in einem Profil zugreifen können.

Informationen zu den zu konfigurierenden Parametern finden Sie unter installKeyPair(). Diese Funktion funktioniert in Verbindung mit der vorhandenen API zum Verwalten von Zertifikaten.

Bereitstellungsszenario

Ohne die Methode installKeyPair():

Nutzer müssen jedes Mal auf den Namen des Zertifikats und dann auf Zulassen tippen, wenn sie Zugriff auf ein Zertifikat gewähren möchten.
Wenn Nutzer ein Zertifikat installieren, wird eine Eingabeaufforderung angezeigt und sie müssen einen Namen dafür eingeben.

Mit der Methode installKeyPair():

Nutzer müssen nicht jedes Mal auf Zulassen tippen, wenn sie Zugriff auf ein Zertifikat gewähren möchten.
Nutzer können Zertifikate nicht umbenennen.
Administratoren haben mehr Kontrolle, da sie Zertifikate für Apps blockieren können, die keinen Zugriff auf bestimmte Zertifikate haben sollen.

Clientzertifikat entfernen

Nachdem Sie Zugriff auf ein Clientzertifikat gewährt haben, rufen Sie removeKeyPair() auf, um Clientzertifikate, die über installKeyPair() installiert wurden, aus der Ferne zu entfernen.

Ein DPC, der im Modus „Geräteeigentümer“ oder „Profilinhaber“ ausgeführt wird, oder ein delegiertes Zertifikatinstallationsprogramm kann removeKeyPair() aufrufen. Dadurch wird ein Zertifikat und ein privates Schlüsselpaar entfernt, die unter einem bestimmten Alias für den privaten Schlüssel installiert sind.

Bereitstellungsszenario

Verwenden Sie diese Funktion, wenn eine Organisation zu einer sichereren Form von Clientzertifikaten migrieren möchte. Wenn ein Administrator ein neues Zertifikat einführt und dessen Verteilung viel Zeit in Anspruch nimmt, kann er die verworfenen Zertifikate nach Abschluss der Migration widerrufen.

Sicherer Sicherheitscode zurückgesetzt

Ihr DPC kann das Passwort eines Nutzers zurücksetzen, indem er die Änderung mit einem vorregistrierten, sicheren Token autorisiert. Geräte- und Profilinhaber können sichere APIs zum Zurücksetzen des Sicherheitscodes aufrufen, um die Passwörter der Geräte bzw. Arbeitsprofile zu ändern. Durch das Zurücksetzen des sicheren Sicherheitscodes wird resetPassword() durch die folgenden Verbesserungen ersetzt:

Der DPC kann den Sicherheitscode mithilfe der dateibasierten Verschlüsselung zurücksetzen, bevor der Nutzer das Gerät oder Profil nach einem Geräteneustart entsperrt.
Nach dem Zurücksetzen des Sicherheitscodes werden vom Nutzer authentifizierte Schlüssel im Android-Schlüsselspeicher aufbewahrt.

Du solltest den sicheren Sicherheitscode zurücksetzen, wenn dein DPC-Build auf Android 8.0 (API-Level 26) oder höher ausgerichtet ist. Durch den Aufruf von resetPassword() wird ein SecurityException in DPCs ausgegeben, die auf Android 8.0 oder höher ausgerichtet sind. In diesem Fall müssen Sie möglicherweise Ihren DPC aktualisieren.

Token festlegen und aktivieren

Der DPC muss vor dem Zurücksetzen eines Passworts ein Token einrichten und aktivieren. Da Ihr DPC das Token möglicherweise nicht sofort verwenden kann, sollten Sie das Token vor der Zeit stellen, die ein IT-Administrator möglicherweise benötigt.

Ein Token zum Zurücksetzen des Passworts ist ein kryptografisch starker Zufallswert und muss mindestens 32 Byte lang sein. Erstellen Sie für jedes Gerät und Profil ein Token. Verwenden Sie die generierten Tokens nicht und teilen Sie sie nicht.

Wir empfehlen, Tokens oder die Mittel zum Entschlüsseln eines verschlüsselten Tokens auf einem Server zu speichern. Wenn Sie Tokens lokal in einem mit Anmeldedaten verschlüsselten Speicher speichern, kann Ihr DPC das Passwort erst zurücksetzen, wenn der Nutzer das Gerät oder Profil entsperrt. Wenn Sie die Tokens lokal im verschlüsselten Speicher des Geräts speichern, der kompromittiert wird, kann ein Angreifer mit dem Token Zugriff auf ein Arbeitsprofil oder einen primären Nutzer erlangen.

Sie können ein neues Token in Ihrem DPC generieren oder ein Token von einem Server abrufen. Das folgende Beispiel zeigt, wie ein DPC selbst ein Token generiert und an einen Server meldet:

Kotlin

val token = ByteArray(32)

// Generate a new token
val random = SecureRandom()
random.nextBytes(token)

// Set the token to use at a later date
val success: Boolean
success = dpm.setResetPasswordToken(DeviceAdminReceiver.getComponentName(context), token)

// Activate the token and update success variable...

// Store the token on a server
if (success) {
 sendTokenToServer(token)
}

Java

byte token[] = new byte[32]; // Minimum size token accepted

// Generate a new token
SecureRandom random = new SecureRandom();
random.nextBytes(token);

// Set the token to use at a later date
boolean success;
success = dpm.setResetPasswordToken(DeviceAdminReceiver.getComponentName(getContext()), token);

// Activate the token and update success variable ...

// Store the token on a server
if (success) {
 sendTokenToServer(token);
}

In den meisten Fällen muss Ihr DPC nach der Einrichtung ein Token aktivieren. Wenn der Nutzer jedoch kein Passwort für den Sperrbildschirm hat, aktiviert das System direkt ein Token. Bitten Sie den Nutzer, seine Anmeldedaten zu bestätigen, um ein Token zu aktivieren. Der DPC kann die KeyguardManager-Methode createConfirmDeviceCredentialIntent() aufrufen, um ein Intent-Element abzurufen, mit dem die Bestätigung gestartet wird. Erläutern Sie dem Gerätenutzer in der Benutzeroberfläche, warum Sie ihn zur Authentifizierung auffordern. Das folgende Snippet zeigt, wie Sie ein Token auf Ihrem DPC aktivieren können:

Kotlin

// In your DPC, you'll need to localize the user prompt
val ACTIVATE_TOKEN_PROMPT = "Use your credentials to enable remote password reset"
val ACTIVATE_TOKEN_REQUEST = 1

// Create or fetch a token and set it in setResetPasswordToken() ...
val keyguardManager = context.getSystemService(Context.KEYGUARD_SERVICE) as KeyguardManager
val confirmIntent = keyguardManager.createConfirmDeviceCredentialIntent(null, ACTIVATE_TOKEN_PROMPT)

if (confirmIntent != null) {
 startActivityForResult(confirmIntent, ACTIVATE_TOKEN_REQUEST)
 // Check your onActivityResult() callback for RESULT_OK
} else {
 // Null means the user doesn't have a lock screen so the token is already active.
 // Call isResetPasswordTokenActive() if you need to confirm
}

Java

// In your DPC, you'll need to localize the user prompt
static final String ACTIVATE_TOKEN_PROMPT =
 "Use your credentials to enable remote password reset";
static final int ACTIVATE_TOKEN_REQUEST = 1;

// Create or fetch a token and set it in setResetPasswordToken() ...

KeyguardManager keyguardManager = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE);
Intent confirmIntent = keyguardManager.createConfirmDeviceCredentialIntent(
  null, ACTIVATE_TOKEN_PROMPT);

if (confirmIntent != null) {
 startActivityForResult(confirmIntent, ACTIVATE_TOKEN_REQUEST);
 // Check your onActivityResult() callback for RESULT_OK
} else {
 // Null means the user doesn't have a lock screen so the token is already active.
 // Call isResetPasswordTokenActive() if you need to confirm
}

Sie müssen ein Token aktivieren, das Ihr DPC festlegt, bevor das Gerät neu gestartet wird. Android speichert ein nicht aktiviertes Token im Arbeitsspeicher und speichert das Token nach einem Neustart nicht weiter. Wenn der Nutzer das Gerät neu startet, bevor er ein Token aktiviert, kann Ihr DPC dasselbe Token noch einmal festlegen oder ein neues Token generieren.

Der DPC kann durch Aufrufen von isResetPasswordTokenActive() bestätigen, dass ein Token aktiv ist. Das Ergebnis sollte true lauten.

Nachdem Ihr DPC ein Token festgelegt und aktiviert hat, ist es gültig, bis es vom DPC gelöscht oder ersetzt oder das Gerät auf die Werkseinstellungen zurückgesetzt wurde. Das Token ist unabhängig vom Passwort und wird nicht davon beeinflusst, dass der Nutzer das Passwort ändert oder löscht.

Token löschen

Sie können clearResetPasswordToken() aufrufen, um ein Token zu löschen, das Ihr DPC zuvor festgelegt hat. Möglicherweise müssen Sie ein gehacktes Token widerrufen oder die Möglichkeit zum Zurücksetzen des Passworts entfernen. Das folgende Beispiel zeigt, wie Sie dies in Ihrem DPC tun können:

Kotlin

val dpm = getDpm()
val admin = DeviceAdminReceiver.getComponentName(requireActivity())

// Clear the token
if (!dpm.clearResetPasswordToken(admin)) {
 // Report the failure and possibly try later ...
}

Java

DevicePolicyManager dpm = getDpm();
ComponentName admin = DeviceAdminReceiver.getComponentName(getActivity());

// Clear the token
if (!dpm.clearResetPasswordToken(admin)) {
 // Report the failure and possibly try later ...
}

Passwort zurücksetzen

Wenn ein IT-Administrator das Passwort zurücksetzen muss, rufen Sie resetPasswordWithToken() auf und übergeben Sie das Token, das Ihr DPC vorab festgelegt und aktiviert hat:

Kotlin

val token: ByteArray = getTokenFromServer()
val newPassword = "password"

try {
 val result: Boolean = dpm.resetPasswordWithToken(
 DeviceAdminReceiver.getComponentName(requireContext()),
 newPassword,
 token,
 0
 )

 if (result) {
 // The password is now 'password'
 } else {
 // Using 'password' doesn't meet password restrictions
 }
} catch (e: IllegalStateException) {
 // The token doesn't match the one set earlier.
}

Java

byte token[] = getTokenFromServer();
String newPassword = "password";

try {
 boolean result = dpm.resetPasswordWithToken(
  DeviceAdminReceiver.getComponentName(getContext()), newPassword, token, 0);

 if (result) {
 // The password is now 'password'
 } else {
 // Using `password` doesn't meet password restrictions
 }
} catch (IllegalStateException e) {
 // The token doesn't match the one set earlier.
}

Ein Aufruf von resetPasswordWithToken() gibt false zurück und das Passwort ändert sich nicht, wenn das neue Passwort die folgenden Einschränkungen nicht erfüllt:

Die Anzahl der Zeichen entspricht der vorgegebenen Mindestlänge des Passworts. Rufen Sie getPasswordMinimumLength() auf, um zu erfahren, ob ein IT-Administrator eine Längenbeschränkung festgelegt hat.
Der Umfang und die Komplexität der Zeichen im Passwort entsprechen einer Beschränkungsbeschränkung. Rufen Sie getPasswordQuality() auf, um zu erfahren, ob ein IT-Administrator eine Zusammensetzungseinschränkung festgelegt hat.

Wenn kein Passwort festgelegt werden muss, können Sie null oder einen leeren String an resetPasswordWithToken() übergeben, um das Passwort zu entfernen.

Sicherheitsherausforderung des Arbeitsprofils

Bei einem DPC, der im Profilinhabermodus ausgeführt wird, müssen Nutzer unter Umständen eine Sicherheitsherausforderung für Anwendungen angeben, die im Arbeitsprofil ausgeführt werden. Das System zeigt die Sicherheitsherausforderung an, wenn der Nutzer versucht, geschäftliche Apps zu öffnen. Wenn der Nutzer die Sicherheitsaufgabe erfolgreich abschließt, entsperrt das System das Arbeitsprofil und entschlüsselt es gegebenenfalls.

So funktioniert die Sicherheitsabfrage für Arbeitsprofile

Wenn ein DPC einen ACTION_SET_NEW_PASSWORD-Intent sendet, wird der Nutzer vom System aufgefordert, eine Sicherheitsabfrage einzurichten.
Der DPC kann auch einen ACTION_SET_NEW_PARENT_PROFILE_PASSWORD-Intent senden, um den Nutzer aufzufordern, eine Gerätesperre einzurichten.

Ein DPC kann die Passwortrichtlinien für die geschäftliche Herausforderung anders festlegen als die Richtlinien für andere Gerätepasswörter. Beispielsweise kann sich die Mindestlänge für die Identitätsbestätigung für ein Gerät von der Länge für andere Passwörter unterscheiden. Ein DPC legt die Richtlinien für die Identitätsbestätigung mit den üblichen DevicePolicyManager-Methoden wie setPasswordQuality() und setPasswordMinimumLength() fest.

Wissenswertes

Der DPC kann das Passwort im Arbeitsprofil zurücksetzen, aber nicht das Gerätepasswort (privates). Wenn ein Nutzer dasselbe geschäftliche und ein privates Passwort festlegt, sorgt resetPassword() im Arbeitsprofil dafür, dass das Passwort nur im Arbeitsprofil und nicht mit dem Passwort für den Sperrbildschirm des Geräts zurückgesetzt wird.
Ein DPC kann den Anmeldebildschirm mit setOrganizationColor() und setOrganizationName() für die geschäftliche Herausforderung anpassen.
Geräteadministratoren können mit resetPassword() keine Passwörter löschen oder bereits festgelegte ändern. Geräteadministratoren können weiterhin ein Passwort festlegen, aber nur, wenn das Gerät kein Passwort, keine PIN und kein Muster hat.

Weitere Informationen finden Sie unter getParentProfileInstance() und in der Referenzdokumentation unter DevicePolicyManager.