Sicherheit

In diesem Leitfaden werden Funktionen der Sicherheitsverwaltung beschrieben, die Sie in Ihrer Device Policy Controller App (DPC) implementieren Dieses Dokument enthält Codebeispiele. Sie können auch die Test DPC App als eine Quelle mit Beispielcode für die Unternehmensfunktionen von Android.

Eine DPC-App kann im Modus „Profilinhaber“ auf privaten Geräten oder im Geräteeigentümer ausgeführt werden auf vollständig verwalteten Geräten. In dieser Tabelle sehen Sie, welche Funktionen Wenn der DPC im Modus „Profilinhaber“ oder „Geräteinhaber“ ausgeführt wird:

Funktion	Profilinhaber	Geräteeigentümer
Zugriff auf Apps deaktivieren	✓	✓
Apps aus unbekannten Quellen blockieren	✓	✓
Konten bei Google Play einschränken	✓	✓
Schutz für zurückgesetzte Geräte aktivieren		✓
Überwachen von Unternehmensprozessprotokollen und Fehlerberichten per Remotezugriff		✓
Zugriff auf ein Clientzertifikat gewähren und aufheben	✓	✓
Sicherheitscode zurücksetzen	✓	✓
Sicherheitsherausforderung des Arbeitsprofils	✓

Zugriff auf Apps deaktivieren

Für Organisationen, die Mitarbeiter daran hindern möchten, Spiele zu spielen oder zuzusehen YouTube auf Android-Geräten zu bestimmten Tageszeiten nutzen oder an bestimmten Wochentagen kann ein DPC den Zugriff auf Apps vorübergehend deaktivieren.

Zum Deaktivieren des Zugriffs auf Apps muss ein DPC im Modus „Geräteinhaber“ oder „Profilinhaber“ ausgeführt werden. konfiguriert setPackagesSuspended() und die ausgewählte App verhält sich dann so die App deaktiviert ist (im Google Launcher wird die App ausgegraut). Wenn Nutzende auf die App tippen, erscheint ein Systemdialogfeld mit der Meldung, dass die App gesperrt ist.

Solange eine App gesperrt ist, kann sie keine Aktivitäten starten. Paket unterdrückt. Gesperrte Pakete werden nicht in der Übersicht angezeigt angezeigt werden, können keine Dialogfelder angezeigt werden (einschließlich Pop-ups und Snackbars). kann keine Audioinhalte abspielen oder das Gerät vibrieren.

Launcher können herausfinden, ob eine App gesperrt ist, indem sie die isPackageSuspended()-Methode. Weitere Informationen zum Konfigurieren der App Sperrung, siehe setPackagesSuspended.

Apps aus unbekannten Quellen blockieren

Apps, die nicht über Google Play oder andere vertrauenswürdige App-Shops installiert wurden, namens Apps aus unbekannten Quellen. Geräte und Daten können einem erhöhten Risiko ausgesetzt sein wenn Nutzer diese Apps installieren.

Um zu verhindern, dass jemand Apps aus unbekannten Quellen installiert, auf vollständig verwalteten Geräten und Arbeitsprofilen DISALLOW_INSTALL_UNKNOWN_SOURCES-Nutzereinschränkung.

Geräteübergreifende Einschrä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 Werks Profil das gesamte Gerät einschränken kann, indem Sie verwaltete Konfiguration für Google Play. Die geräteübergreifende Einschränkung ab Android 8.0 verfügbar, wenn die installierte Google Play App Version 80812500 oder höher.

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

1. Set mit einer verwalteten Konfiguration für das Google Play-Paket festlegen com.android.vending
2. Setzen Sie im Bundle einen booleschen Wert für den verify_apps:device_wide_unknown_source_block-Schlüssel.
3. Fügen Sie die Nutzereinschränkung ENSURE_VERIFY_APPS hinzu.

Das folgende Beispiel zeigt, wie Sie prüfen können, ob Google Play diese und legen Sie den Wert auf true fest:

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, aber das System blockiert App-Installation. Diese Einschränkung betrifft zukünftige Installationen – bleiben installierte Apps auf dem Gerät. Gerätenutzer können weiterhin Apps installieren mit der Android Debug Bridge (ADB) in das private Profil importieren.

Weitere Informationen zu unbekannten Quellen finden Sie unter Alternative Verteilung Optionen.

Konten in Google Play einschränken

Manchmal möchte eine Organisation Personen erlauben, private Google-Konten Konten (um E-Mails in Gmail zu lesen), aber nicht möchten, dass die privaten -Konto, um Apps zu installieren. Ihr DPC kann eine Liste von Konten erstellen, in denen Nutzer verwenden können Google Play

Für Administratorkomponenten von vollständig verwalteten Geräten oder Arbeitsprofilen kann die Nutzung indem Sie eine verwaltete Konfiguration für Google Play festlegen. Das Konto Die Einschränkung ist verfügbar, wenn die installierte Google Play-App die Version 80970100 ist oder höher.

So schränken Sie die Anzahl der Konten in Google Play ein:

1. Set mit einer verwalteten Konfiguration für das Google Play-Paket festlegen com.android.vending
2. Geben Sie im Set die durch Kommas getrennten E-Mail-Adressen als Stringwert für den allowed_accounts-Schlüssel.

Das folgende Beispiel zeigt, wie Sie die Anzahl der Konten begrenzen 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 = "[e-mail],[e-mail]"

// 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 = "[e-mail],[e-mail]";

// 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 auf das Arbeitskonto beschränken möchten, legen Sie für allowed_accounts den folgenden Wert fest: sobald Ihr DPC die E-Mail-Adresse des Kontos kennt. Eine Wenn ein String leer ist, können Nutzer kein Konto bei Google Play verwenden.

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

Mithilfe des Schutzes für zurückgesetzte Geräte können Organisationen festlegen, Geräte, die auf die Werkseinstellungen zurückgesetzt wurden, können über Google-Konten bereitgestellt werden.

Der Schutz für zurückgesetzte Geräte wurde entwickelt, um Diebstahl von Geräten zu verhindern. Vorher damit jeder das Gerät bereitstellen kann, nachdem es nicht auf die Werkseinstellungen zurückgesetzt wurde (z. B. wie ein EMM-Anbieter verwendet wird, muss sich der Nutzer im Einrichtungsassistenten bei Google-Konten, die sich zuvor im privaten Profil des Geräts befanden.

In Unternehmen ist das Zurücksetzen auf die Werkseinstellungen ein wichtiges Tool zur Verwaltung Mitarbeitergeräte verwendet, wenn ein Mitarbeiter die Organisation verlässt. Wenn die Organisation kennt die Anmeldedaten für das Konto eines Mitarbeiters nicht, zurückgesetzt kann die Organisation daran hindern, ein Gerät an eine andere Person .

Hinweis: Der Schutz vor Zurücksetzen auf die Werkseinstellungen ist deaktiviert, wenn die OEM-Entsperrung aktiviert ist in Entwickleroptionen.

Bereitstellung nach dem Zurücksetzen auf die Werkseinstellungen steuern

Im Modus „Geräteeigentümer“ kann Ihr DPC Folgendes verwenden: setFactoryResetProtectionPolicy(), um zu steuern, welche Konten autorisiert ist, ein Gerät nach dem Zurücksetzen auf die Werkseinstellungen bereitzustellen. Wenn diese Konfiguration auf null festgelegt oder auf eine leere Liste festgelegt ist, werden die für die Bereitstellung autorisierten Konten nach dem Zurücksetzen auf die Werkseinstellungen handelt es sich um die Konten im privaten Profil des Geräts, .

Ein DPC kann diese Konten während der gesamten Lebensdauer einer vollständig verwalteten .

Hinweis: Der DPC verwendet den Wert userID, um zu konfigurieren, welche Konten Daten bereitstellen können. nach dem Zurücksetzen auf die Werkseinstellungen wieder auf ein Gerät übertragen.

1. Der IT-Administrator kann die Methode people.get über die People API verwenden mit dem speziellen Wert me. Dadurch wird der userId für den angemeldet sind. userID wird im Schlüssel resourceName zurückgegeben in das Format people/[userId] als ganzzahligen String. Neu erstellte Konten können sind 72 Stunden lang nicht für das Zurücksetzen auf die Werkseinstellungen verfügbar.
2. Möglicherweise möchten Sie auch einem oder mehreren IT-Administratoren die Berechtigung erteilen, das Gerät anschließend wieder zu entsperren. auf die Werkseinstellungen zurücksetzen. Bitten Sie alle IT-Administratoren, sich in ihrem Google-Konto anzumelden führen Sie auch Schritt 1 aus und geben Sie die userId für Sie frei, damit Sie diese userIds der Liste im nächsten Schritt hinzu.
3. Der DPC legt eine entsprechende App-Einschränkung mithilfe von Mit setFactoryResetProtectionPolicy() legen Sie die Liste der userId fest, die ein auf die Werkseinstellungen zurückgesetztes Gerät bereitstellen.
4. Der DPC aktiviert die Konten, die Geräte nach der Fabrik bereitstellen können indem Sie die Nachricht an alle com.google.android.gms.auth.FRP_CONFIG_CHANGED als expliziten Intent verhindern, dass sie aufgrund von Hintergrundbeschränkungen verworfen 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

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

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 für zurückgesetzte Geräte von Unternehmen deaktivieren

Um den Schutz für zurückgesetzte Geräte zu deaktivieren, kann Ihr DPC Folgendes verwenden: setFactoryResetProtectionPolicy()Der Wert null wird ü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

Für Geräte, die setFactoryResetProtectionPolicy() nicht verwenden können, eingeführt mit API-Level 30 – Ihr DPC kann mit setApplicationRestrictions einen Schlüssel festlegen Wert von true im verwalteten disableFactoryResetProtectionAdmin Konfiguration für das Paket com.google.android.gms.

Hinweis: Wenn Sie die verwaltete factoryResetProtectionAdmin-Konfiguration nicht konfigurieren, deaktiviert den Schutz vor Zurücksetzen auf die Werkseinstellungen nicht.

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 Remotezugriff

In der EMM-Konsole kann ein Administrator vollständig verwaltete Geräte über das Unternehmen überwachen Prozessprotokolle und Remote-Fehlerberichte.

Aktivität von Unternehmensgeräten protokollieren

Ein DPC, der im Modus „Geräteinhaber“ ausgeführt wird, kann verdächtige Aktivitäten per Remotezugriff auf Tracking von Geräteaktivitäten, einschließlich App-Starts, Android Debug Bridge (ADB) und das Entsperren des Displays. Für Prozessprotokolle ist keine Nutzereinwilligung erforderlich.

Zum Aktivieren oder Deaktivieren der Protokollierung ruft ein DPC setSecurityLoggingEnabled() auf.

Wenn ein neuer Batch von Logs verfügbar ist, empfängt ein DeviceAdminReceiver den onSecurityLogsAvailable()-Rückruf. So rufen Sie die Protokolle ab (nach Empfang des Callbacks), ruft ein DPC retrieveSecurityLogs() auf.

DPCs können auch retrievePreRebootSecurityLogs() aufrufen, um Sicherheitsdaten abzurufen Logs, die im vorherigen Neustartzyklus generiert wurden. Das ist das Intervall zwischen den letzten Geräteneustart und den vorherigen Neustart. Geräte ohne Unterstützung retrieveSecurityLogs() gibt null zurück. Wenn Ihre Anwendung Logs sowohl mit retrievePreRebootSecurityLogs() und retrieveSecurityLogs(), du musst nach doppelten Einträgen zu suchen.
Hinweis: Diese Funktion protokolliert nur Aktivitäten auf vollständig verwalteten Geräten mit einem einzigen Nutzer oder verknüpfte Nutzer des Geräts. Diese Funktion ist nicht verfügbar auf privaten Geräten, da damit geräteübergreifende Aktivitäten protokolliert werden.

Diese Einstellung kann bei der Überwachung von Sicherheitsereignissen nützlich sein, da sie folgenden Aktionstypen:

• Jedes Mal, wenn die App neu gestartet wird. So lässt sich feststellen, Malware, die mit einer manipulierten App beginnt.
• Fehlgeschlagene Entsperrversuche auf einem Gerät So könnten Sie feststellen, mehrere fehlgeschlagene Entsperrversuche innerhalb kurzer Zeit.
• Potenziell schädliche ADB-Befehle, wenn ein Nutzer eine Verbindung herstellt das Gerät über ein USB-Kabel an einen Computer an.

Weitere Informationen zum Lesen von Logs finden Sie unter SecurityLog.

Beim Entwickeln und Testen können Sie das System dazu zwingen, vorhandene Sicherheitsprotokolle für Ihren DPC verfügbar sind. Sie müssen nicht auf einen vollständigen zu erstellen. Führen Sie unter Android 9.0 (API-Level 28) oder höher folgenden Befehl aus: Android Debug Bridge (adb) in Ihrem Terminal:

adb shell dpm force-security-logs

Die Häufigkeit, mit der Sie das Tool verwenden können, wird vom System begrenzt. in der Terminalausgabe bewusst verlangsamt. Falls Logs verfügbar sind, DPC empfängt den onSecurityLogsAvailable()-Callback.

Fehlerbericht aus der Ferne anfordern

Ein DPC, der im Modus „Geräteinhaber“ ausgeführt wird, kann per Fernzugriff Fehlerberichte für den Nutzer anfordern Geräte mit nur einem Nutzer oder verknüpften Nutzer Der Fehlerbericht enthält Geräteaktivität genau in dem Moment, in dem der Fehlerbericht angefordert wird, Aktivitäten der letzten Stunden enthalten, je nachdem, wie oft ein Logcat zum Zwischenspeichern.

Zur Remote-Anfrage für Fehlerberichte ruft der DPC requestBugreport() auf:

• Wenn ein Nutzer die Weitergabe des Fehlerberichts akzeptiert, erhält der DPC den Fehler Bericht mit onBugreportShared()
• Wenn ein Nutzer die Freigabe des Fehlerberichts ablehnt, erhält der DPC eine Freigabe Anfrage abgelehnt Nachricht mit onBugreportSharingDeclined()
• 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 Modus „Profilinhaber“ oder „Geräteinhaber“ ausgeführt wird, eine Drittanbieter-App gewährt die Möglichkeit, Zertifikate zu verwalten, kann sich die App selbst Zugriff auf Zertifikate, die ohne Nutzereingriff installiert werden. So installieren Sie ein Zertifikat, auf das alle Apps in einem Profil zugreifen können, installKeyPair() verwenden.

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. möchten Sie Zugriff auf ein Zertifikat gewähren.
• Nutzer sehen bei der Installation eines Zertifikats eine Aufforderung und müssen den Namen des Zertifikat.

Mit der Methode installKeyPair():

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

Clientzertifikat entfernen

Nach dem Gewähren des Zugriffs auf ein Clientzertifikat, um den Client per Fernzugriff zu entfernen über installKeyPair() installiert haben, rufen Sie removeKeyPair()

Ein DPC, der im Modus „Geräteinhaber“ oder „Profilinhaber“ ausgeführt wird oder delegiert wurde Das Zertifikat-Installationsprogramm kann removeKeyPair() aufrufen. Dadurch wird Folgendes entfernt: ein Zertifikat und ein privates Schlüsselpaar, das unter einem bestimmten Alias für den privaten Schlüssel installiert ist.

Bereitstellungsszenario

Verwenden Sie diese Funktion, wenn eine Organisation zu einer sichereren Clientform migriert Zertifikat. Wenn ein Administrator ein neues Zertifikat einführt und dessen Verteilung sehr lange dauert, kann der Administrator das eingestellte nach Abschluss der Migration.

Sicheren Sicherheitscode zurücksetzen

Ihr DPC kann das Passwort eines Nutzers zurücksetzen, indem er die Änderung mit einem ein vorab registriertes, sicheres Token. Geräteinhaber und Profilinhaber können sichere Anrufe tätigen APIs zum Zurücksetzen von Sicherheitscodes, um das Passwort von Geräten und Arbeitsprofilen zu ändern . Beim Zurücksetzen des sicheren Sicherheitscodes wird resetPassword() durch den folgende Verbesserungen:

• Ihr DPC kann den Sicherheitscode zurücksetzen, bevor der Nutzer das Gerät oder Profil entsperrt nach einem Neustart auf Geräten mit dateibasierter Verschlüsselung.
• Der Android Keystore speichert vom Nutzer authentifizierte Schlüssel. nach dem Zurücksetzen des Sicherheitscodes.

Sie sollten den sicheren Sicherheitscode zurücksetzen, wenn Ihr DPC-Build auf Android 8.0 (API) ausgerichtet ist Level 26) oder höher. Durch den Aufruf von resetPassword() wird Folgendes ausgelöst: SecurityException in DPCs, die auf Android 8.0 oder höher ausgerichtet sind. müssen Sie Ihren DPC aktualisieren.

Token festlegen und aktivieren

Ihr DPC muss vor dem Zurücksetzen eines Passworts ein Token festlegen und aktivieren. Weil kann Ihr DPC das Token möglicherweise nicht sofort verwenden, wenn ein IT-Administrator sie verwenden muss.

Ein Token zum Zurücksetzen des Passworts ist ein kryptografisch starker Zufallswert und muss mindestens 32 Byte lang sein. Erstelle für jedes Gerät und Profil ein Token – Ihre generierten Tokens wiederverwenden oder teilen.

Warnung: Behandeln Sie das Token wie Nutzeranmeldedaten. Speichern Sie die Token auf dem Gerät als Nur-Text, insbesondere im verschlüsselten Speicher des Geräts. Ihr Unternehmen sorgfältig überlegen, wie sie die Tokens auf einem Server speichern und wer Zugriff auf die Tokens erhält. Tokens können Gegenstand rechtlicher Ersuchen Gerätezugriff.

Wir empfehlen, Tokens oder die Methoden zum Entschlüsseln eines verschlüsselten Tokens auf einem Server. Wenn Sie Tokens lokal im mit Anmeldedaten verschlüsselten Speicher speichern, kann das Passwort erst zurücksetzen, wenn der Nutzer das Gerät oder Profil entsperrt. Wenn Sie die Token lokal im Geräteverschlüsselungsspeicher speichern, Ein Angreifer könnte mithilfe des Tokens Zugriff auf ein Arbeitsprofil oder eine primäre Nutzer.

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

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 ein Token aktivieren, nachdem es festgelegt wurde. Wenn Sie jedoch Wenn der Nutzer kein Passwort für den Sperrbildschirm hat, aktiviert das System ein Token. und zwar sofort. Bitten Sie den Nutzer, seine Anmeldedaten zu bestätigen, um ein Token zu aktivieren. Ihr DPC kann die Methode KeyguardManager aufrufen createConfirmDeviceCredentialIntent(), um ein Intent zu erhalten, das bestätigen. Erklären Sie dem Gerätenutzer auf der Benutzeroberfläche, warum Sie zur Authentifizierung. Das folgende Snippet zeigt, wie Sie ein Token in Ihrem DPC:

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 von Ihrem DPC festgelegt wird, bevor das Gerät neu gestartet wird. Android-Geräte speichert ein nicht aktiviertes Token im Arbeitsspeicher und behält das Token nach einer neu starten. Wenn der Nutzer das Gerät neu startet, bevor ein Token aktiviert wurde, kann Ihr DPC Legen Sie dasselbe Token noch einmal fest oder generieren Sie ein neues Token.

Ihr DPC kann durch den Aufruf von isResetPasswordTokenActive() und das Ergebnis wird geprüft: true.

Nachdem Ihr DPC ein Token festgelegt und aktiviert hat, ist es so lange gültig, bis es von Ihrem DPC gelöscht oder ersetzt das Token (oder das Gerät wird auf die Werkseinstellungen zurückgesetzt). Das Token ist unabhängig von das Passwort und wird nicht durch das Ändern oder Löschen des Passworts durch den Nutzer beeinflusst.

Token löschen

Sie können clearResetPasswordToken() aufrufen, um ein Token zu löschen, das Ihr DPC festgelegt haben. Eventuell müssen Sie ein manipuliertes Token widerrufen oder entfernen Sie die Möglichkeit, das Passwort zurückzusetzen. Im Beispiel unten sehen Sie, wie Sie in Ihrem DPC:

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() und übergeben Sie das Token, das von Ihrem DPC festgelegt und aktiviert wurde im Voraus:

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, aber das Passwort nicht geändert werden, wenn das neue Passwort die folgenden Bedingungen nicht erfüllt:

• Die Anzahl der Zeichen entspricht der Beschränkung für die Mindestpasswortlänge. Anruf getPasswordMinimumLength(), um zu erfahren, ob ein IT- Der Administrator hat eine Längenbeschränkung festgelegt.
• Der Umfang und die Komplexität der Zeichen im Passwort stimmen mit einer Zusammensetzung überein. Einschränkung. Rufen Sie getPasswordQuality() an, um zu erfahren, ob ein IT- Der Administrator hat eine Kompositionseinschränkung festgelegt.

Wenn aufgrund der Qualitätsbeschränkungen für Passwörter kein Passwort festgelegt werden muss, können Sie Übergeben Sie null oder einen leeren String an resetPasswordWithToken(), um den Passwort.

Sicherheitsherausforderung des Arbeitsprofils

Bei einem DPC, der im Profilinhabermodus ausgeführt wird, müssen Nutzer möglicherweise eine Sicherheitseinstellung angeben für Apps, die im Arbeitsprofil ausgeführt werden. Das System zeigt die Sicherheit wenn der Nutzer versucht, geschäftliche Apps zu öffnen. Wenn der Nutzer die Sicherheitsherausforderung abgeschlossen, entsperrt das System das Arbeitsprofil bei Bedarf entschlüsselt.

Hinweis :Die separate Work-Challenge ist eine Funktion, die auch vom Nutzer festgelegt werden kann. Der Nutzer wählt die vereinheitlichte Sperre aus und kann auf geschäftliche Apps zugreifen, sobald er ihre persönliche Sperre am Gerät entsperren.

So funktioniert die Sicherheitsherausforderung für das Arbeitsprofil

1. Wenn ein DPC den Intent ACTION_SET_NEW_PASSWORD sendet, fordert das System den Nutzer bitten, eine Sicherheitsabfrage einzurichten.
2. Der DPC kann auch eine ACTION_SET_NEW_PARENT_PROFILE_PASSWORD Absicht, den Nutzer aufzufordern, eine Gerätesperre einzurichten.

Ein DPC kann die Passwortrichtlinien für die Identitätsbestätigung anders festlegen als die für andere Gerätepasswörter festlegen. Zum Beispiel ist die Mindestlänge Die Reaktion auf die Abfrage des Geräts kann von der Länge abweichen, die für andere Passwörter. Ein DPC legt die Challenge-Richtlinien mithilfe der üblichen DevicePolicyManager-Methoden wie setPasswordQuality() und setPasswordMinimumLength()

Wissenswertes

• Der DPC kann das Passwort im Arbeitsprofil zurücksetzen, aber nicht das (persönliche) Passwort. Wenn ein Nutzer geschäftliche und private Passwörter festlegt gleich sein muss, führt resetPassword() im Arbeitsprofil dazu, dass Das Passwort wird nur im Arbeitsprofil zurückgesetzt und das Passwort ist nicht dasselbe. für den Sperrbildschirm des Geräts.
• Ein DPC kann den Anmeldedatenbildschirm für die Work-Challenge mithilfe von setOrganizationColor() und setOrganizationName()
• Geräteadministratoren können resetPassword() nicht verwenden, um Passwörter zu löschen oder zu ändern bereits festgelegte. Geräteadministratoren können weiterhin ein Passwort festlegen, wenn das Gerät kein Passwort, keine PIN und kein Muster hat.

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