Ta strona została przetłumaczona przez Cloud Translation API.

Bezpieczeństwo

Funkcje w tym przewodniku opisują funkcje zarządzania zabezpieczeniami, które możesz wdrożyć w aplikacji kontrolera zasad urządzeń (DPC). Ten dokument zawiera przykładowy kod. Możesz też użyć aplikacji Test DPC jako źródła przykładowego kodu do obsługi funkcji biznesowych Androida.

Aplikacja DPC może działać w trybie właściciela profilu na urządzeniach osobistych oraz w trybie właściciela urządzenia na urządzeniach w pełni zarządzanych. Ta tabela zawiera informacje o tym, które funkcje są dostępne, gdy DPC działa w trybie właściciela profilu lub właściciela urządzenia:

Funkcja	Właściciel profilu	Właściciel urządzenia
Wyłączanie dostępu do aplikacji	✓	✓
Blokowanie aplikacji z nieznanych źródeł	✓	✓
Ograniczanie dostępu do kont w Google Play	✓	✓
Włączanie ochrony przed zresetowaniem do ustawień fabrycznych w firmie		✓
Monitorowanie dzienników procesów przedsiębiorstwa i zdalnych raportów o błędach		✓
Przyznawanie dostępu i odbieranie dostępu do certyfikatu klienta	✓	✓
Resetowanie bezpiecznego kodu dostępu	✓	✓
Test zabezpieczający profil służbowy	✓

Wyłączanie dostępu do aplikacji

W przypadku organizacji, które chcą zablokować pracownikom możliwość grania w gry lub oglądania filmów w YouTube na urządzeniach z Androidem o określonych porach dnia lub w określone dni tygodnia, DPC może tymczasowo wyłączyć dostęp do aplikacji.

Aby wyłączyć dostęp do aplikacji, DPC działający w trybie właściciela urządzenia lub właściciela profilu konfiguruje setPackagesSuspended(). Następnie wybrana aplikacja działa tak, jakby była wyłączona (program uruchamiający Google wyszarzy aplikację). Gdy użytkownik kliknie aplikację, zobaczy okno systemu z informacją, że aplikacja jest zawieszona.

Gdy aplikacja jest zawieszona, nie może rozpoczynać działań, a powiadomienia wysyłane do pakietu są pomijane. Zawieszone pakiety nie wyświetlają się na ekranie przeglądu, nie mogą wyświetlać okien (w tym tostów i pasków powiadomień) ani odtwarzać dźwięku, ani wibrować urządzenia.

Launchery mogą sprawdzić, czy aplikacja jest zawieszona, wywołując metodę isPackageSuspended(). Szczegółowe informacje o konfigurowaniu zawieszenia aplikacji znajdziesz w artykule setPackagesSuspended.

Blokowanie aplikacji z nieznanych źródeł

Aplikacje, które nie zostały zainstalowane z Google Play (ani z innych zaufanych sklepów z aplikacjami), są nazywane aplikacjami z nieznanych źródeł. Instalacja takich aplikacji może być zwiększona ryzykiem urządzeń i danych.

Aby uniemożliwić użytkownikom instalowanie aplikacji z nieznanych źródeł, administratorzy w pełni zarządzanych urządzeń i profili służbowych mogą dodawać ograniczenie dotyczące użytkownika DISALLOW_INSTALL_UNKNOWN_SOURCES.

Ograniczenie na wszystkich urządzeniach w profilu służbowym

Gdy administrator profilu służbowego doda DISALLOW_INSTALL_UNKNOWN_SOURCES, ograniczenie będzie dotyczyć tylko tego profilu. Administrator profilu służbowego może jednak wprowadzić ograniczenie na poziomie urządzenia, ustawiając konfigurację zarządzaną dla Google Play. Ograniczenie obejmujące całe urządzenie jest dostępne w Androidzie 8.0 (lub nowszym), jeśli zainstalowana aplikacja Google Play to wersja 80812500 lub nowsza.

Aby ograniczyć instalowanie aplikacji do Google Play, wykonaj te czynności:

Ustaw zarządzany pakiet konfiguracji dla pakietu Google Play com.android.vending.
W pakiecie umieść wartość logiczną klucza verify_apps:device_wide_unknown_source_block.
Dodaj ograniczenie dotyczące użytkownika ENSURE_VERIFY_APPS.

Poniższy przykład pokazuje, jak sprawdzić, czy Google Play obsługuje to ustawienie i jak ustawić wartość true:

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);

Interfejs w ustawieniach systemu pozostaje aktywny, ale system blokuje instalację aplikacji. To ograniczenie będzie miało wpływ na przyszłe instalacje – wcześniej zainstalowane aplikacje pozostaną na urządzeniu. Użytkownicy urządzeń mogą nadal instalować aplikacje w profilu osobistym przy użyciu narzędzia Android Debug Bridge (adb).

Więcej informacji o nieznanych źródłach znajdziesz w artykule Alternatywne opcje dystrybucji.

Ograniczanie dostępu do kont w Google Play

Czasami organizacja może zezwalać na dodawanie osobistych kont Google (na przykład do odczytywania poczty w Gmailu), ale nie chce, aby aplikacje były instalowane za pomocą konta osobistego. DPC może określić listę kont, których użytkownicy mogą używać w Google Play.

Administratorzy urządzeń w pełni zarządzanych lub profili służbowych mogą ograniczać dostęp do kont przez ustawienie konfiguracji zarządzanej dla Google Play. Ograniczenie dotyczące konta jest dostępne, gdy zainstalowana aplikacja Google Play jest w wersji 80970100 lub nowszej.

Aby ograniczyć liczbę kont w Google Play:

Ustaw zarządzany pakiet konfiguracji dla pakietu Google Play com.android.vending.
Do pakietu umieść adresy e-mail oddzielone przecinkami jako wartość ciągu znaków dla klucza allowed_accounts.

Ten przykład pokazuje, jak możesz ograniczyć liczbę kont:

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);

Aby ograniczyć Google Play tylko do konta służbowego, ustaw allowed_accounts jako jedno zarządzane konto, gdy tylko DPC pozna adres e-mail konta. Pusty ciąg znaków uniemożliwia korzystanie z żadnego konta w Google Play.

Włącz firmową ochronę przywracania do ustawień fabrycznych

Organizacje korzystające z ochrony przed zresetowaniem do ustawień fabrycznych mogą określić, które konta Google mogą udostępniać urządzenia po przywróceniu do ustawień fabrycznych.

Ochrona przywracania ustawień fabrycznych została zaprojektowana po to, by zapobiegać kradzieży urządzenia. Zanim zezwolisz na obsługę urządzenia po nieautoryzowanym przywróceniu urządzenia do ustawień fabrycznych (np. przy użyciu usług EMM), kreator konfiguracji wymaga od użytkownika uwierzytelnienia na wszystkich kontach Google, które znajdowały się wcześniej na osobistym profilu urządzenia.

W środowisku firmowym resetowanie do ustawień fabrycznych jest ważnym narzędziem do zarządzania urządzeniami pracowników po odejściu pracownika. Jeśli jednak organizacja nie zna danych logowania na konto pracownika, ochrona przed zresetowaniem do ustawień fabrycznych może zablokować możliwość wydania urządzenia innemu pracownikowi.

Kontrolowanie obsługi administracyjnej po przywróceniu ustawień fabrycznych

DPC działa w trybie właściciela urządzenia, aby za pomocą setFactoryResetProtectionPolicy() określać, które konta są uprawnione do udostępniania urządzenia po przywróceniu ustawień fabrycznych. Jeśli ta konfiguracja ma wartość null lub jest pusta, konta autoryzowane do obsługi administracyjnej urządzenia po przywróceniu ustawień fabrycznych są kontami w profilu osobistym urządzenia.

DPC może konfigurować te konta przez cały okres użytkowania w pełni zarządzanego urządzenia.

Administrator IT może użyć metody people.get z interfejsu People API z użyciem specjalnej wartości me. Spowoduje to pobranie wartości userId dla konta po zalogowaniu. userID jest zwracana w kluczu resourceName w postaci people/[userId] jako ciąg całkowita. Nowe konta mogą nie być dostępne do przywrócenia do ustawień fabrycznych przez 72 godziny.
Możesz też umożliwić administratorom IT odblokowywanie urządzenia po przywróceniu ustawień fabrycznych. Poproś każdego z tych administratorów IT o zalogowanie się na swoje konta Google, wykonanie kroku 1 i udostępnienie Ci userId tych kont. Pozwoli Ci to dodać te konta userIds do listy w następnym kroku.
DPC ustawia odpowiednie ograniczenie aplikacji przy użyciu setFactoryResetProtectionPolicy(), aby ustawić listę urządzeń userId, które mogą udostępnić urządzenie przywrócone do ustawień fabrycznych.
DPC włącza konta, które mogą obsługiwać urządzenia po przywróceniu ustawień fabrycznych, wysyłając komunikat com.google.android.gms.auth.FRP_CONFIG_CHANGED w celu uniknięcia utraty danych z powodu ograniczeń działania w tle.

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);

Starszy tryb

W przypadku urządzeń, które nie mogą korzystać z setFactoryResetProtectionPolicy() wprowadzonego w ramach interfejsu API poziomu 30, DPC może użyć konta setApplicationRestrictions, aby dodać wybrane konta do zarządzanej konfiguracji factoryResetProtectionAdmin pakietu com.google.android.gms.

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);

Wyłącz ochronę przed zresetowaniem do ustawień fabrycznych w firmie

Aby wyłączyć ochronę przed zresetowaniem do ustawień fabrycznych, DPC może przekazać setFactoryResetProtectionPolicy()wartość null.

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);

Starszy tryb

W przypadku urządzeń, które nie mogą korzystać z funkcji setFactoryResetProtectionPolicy() (wprowadzonej w ramach interfejsu API poziomu 30), DPC może użyć setApplicationRestrictions, aby ustawić parę klucz-wartość true w konfiguracji zarządzanej disableFactoryResetProtectionAdmin pakietu com.google.android.gms.

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);

Monitorowanie dzienników procesów firmowych i zdalnych raportów o błędach

W konsoli EMM administrator może monitorować w pełni zarządzane urządzenia przy użyciu dzienników procesów firmowych i zdalnych raportów o błędach.

Rejestruj aktywność na urządzeniach firmowych

DPC działający w trybie właściciela urządzenia może wykryć podejrzaną aktywność, zdalnie śledząc aktywność na urządzeniu, w tym uruchamianie aplikacji, aktywność w usłudze Android Debug Bridge (adb) i odblokowania ekranu. Dzienniki procesów nie wymagają zgody użytkownika.

Aby włączyć lub wyłączyć logowanie, DPC wywołuje metodę setSecurityLoggingEnabled().

Gdy dostępna będzie nowa grupa logów, DeviceAdminReceiver otrzyma wywołanie zwrotne onSecurityLogsAvailable(). Aby pobrać dzienniki (po otrzymaniu wywołania zwrotnego), DPC wywołuje retrieveSecurityLogs().

DPC może też wywoływać metodę retrievePreRebootSecurityLogs(), aby pobrać logi zabezpieczeń wygenerowane w poprzednim cyklu ponownego uruchamiania. Jest to czas między ostatnim ponownym uruchomieniem urządzenia a poprzednim restartem. Urządzenia, które nie obsługują funkcji retrieveSecurityLogs(), zwracają wartość null. Jeśli aplikacja pobiera logi przy użyciu obu metod: retrievePreRebootSecurityLogs() i retrieveSecurityLogs(), musisz sprawdzić, czy nie ma zduplikowanych wpisów.
Uwaga: ta funkcja rejestruje tylko aktywność na w pełni zarządzanych urządzeniach jednego użytkownika lub powiązanych użytkowników. Ta funkcja nie działa na urządzeniach osobistych, ponieważ rejestruje aktywność na wszystkich urządzeniach.

To ustawienie może być przydatne podczas kontroli zdarzeń po zdarzeniach związanych z bezpieczeństwem, ponieważ rejestruje następujące typy działań:

Przy każdym uruchomieniu aplikacji. Może to pomóc w ustaleniu, czy złośliwe oprogramowanie zaczyna się od zaatakowanej aplikacji.
Nieudane próby odblokowania urządzenia. Może to pomóc ustalić, czy w krótkim czasie doszło do kilku nieudanych prób odblokowania urządzenia.
potencjalnie szkodliwe polecenia adb, gdy użytkownik łączy urządzenie z komputerem za pomocą kabla USB.

Szczegółowe informacje o tym, jak odczytywać logi, znajdziesz w artykule SecurityLog.

W czasie programowania i testowania możesz wymusić w systemie udostępnienie istniejących logów zabezpieczeń DPC – nie musisz czekać na całą serię. Na Androidzie 9.0 (poziom interfejsu API 28) lub nowszym uruchom w terminalu to polecenie Android Debug Bridge (adb):

adb shell dpm force-security-logs

System ogranicza częstotliwość, z jaką możesz używać narzędzia, i zgłasza wszelkie przypadki planowanego spowolnienia działania terminala. Jeśli dostępne są logi, DPC otrzyma wywołanie zwrotne onSecurityLogsAvailable().

Zdalnie poproś o raport o błędzie

DPC uruchomiony w trybie właściciela urządzenia może zdalnie prosić o raporty o błędach dotyczące urządzeń, z którymi jest tylko 1 użytkownik lub powiązanych użytkowników. Raport o błędzie rejestruje aktywność urządzenia dokładnie w momencie przesłania prośby o raport, ale może też obejmować aktywność z ostatnich kilku godzin, w zależności od tego, jak często odświeżany jest bufor Logcat.

Aby zdalnie poprosić o raport o błędzie, DPC wywołuje requestBugreport():

Jeśli użytkownik zaakceptuje udostępnienie raportu o błędzie, DPC otrzyma raport o błędzie za pomocą onBugreportShared().
Jeśli użytkownik odmówi udostępnienia raportu o błędzie, DPC otrzyma wiadomość o odrzuceniu prośby o udostępnienie za pomocą onBugreportSharingDeclined().
Jeśli raport o błędzie nie powiedzie się, DPC zobaczy symbol onBugreportFailed() z wartością BUGREPORT_FAILURE_FAILED_COMPLETING lub BUGREPORT_FAILURE_FILE_NO_LONGER_AVAILABLE.

Przyznawanie dostępu i odbieranie dostępu do certyfikatu klienta

Jeśli DPC działający w trybie właściciela profilu lub urządzenia umożliwia aplikacji innej firmy zarządzanie certyfikatami, może ona bez ingerencji użytkownika przyznawać sobie dostęp do instalowanych certyfikatów. Aby zainstalować certyfikat, do którego mają dostęp wszystkie aplikacje w profilu, użyj installKeyPair().

Parametry, które należy skonfigurować, znajdziesz w sekcji installKeyPair(). Ta funkcja działa w połączeniu z dotychczasowym interfejsem API do zarządzania certyfikatami.

Scenariusz wdrożenia

Bez metody installKeyPair():

Użytkownicy muszą kliknąć nazwę certyfikatu i kliknąć Zezwól za każdym razem, gdy chcą przyznać dostęp do certyfikatu.
Podczas instalowania certyfikatu użytkownicy widzą monit o podanie nazwy certyfikatu.

W przypadku metody installKeyPair():

Użytkownicy nie muszą klikać Zezwól za każdym razem, gdy chcą przyznać dostęp do certyfikatu.
Użytkownicy nie mogą zmieniać nazw certyfikatów.
Administratorzy mają większą kontrolę, ponieważ mogą blokować certyfikaty aplikacji, które nie powinny mieć dostępu do konkretnych certyfikatów.

Usuwanie certyfikatu klienta

Aby po przyznaniu dostępu do certyfikatu klienta zdalnie usunąć certyfikaty klienta zainstalowane za pomocą installKeyPair(), wywołaj metodę removeKeyPair().

DPC działający w trybie właściciela urządzenia lub właściciela profilu albo instalator delegowanego certyfikatu może wywołać metodę removeKeyPair(). Spowoduje to usunięcie pary certyfikatów i kluczy prywatnych zainstalowanych w ramach danego aliasu klucza prywatnego.

Scenariusz wdrożenia

Użyj tej funkcji, jeśli organizacja przechodzi na bezpieczniejszą formę certyfikatu klienta. Jeśli administrator wdraża nowy certyfikat, a jego rozpowszechnianie trwa długo, może on unieważnić wycofane certyfikaty po zakończeniu migracji.

Zresetowano bezpieczny kod dostępu

DPC może zresetować hasło użytkownika, autoryzując zmianę za pomocą wcześniej zarejestrowanego, bezpiecznego tokena. Właściciele urządzeń i właściciele profili mogą wywoływać bezpieczne interfejsy API resetowania kodów dostępu, aby odpowiednio zmieniać hasła na urządzeniach i w profilach służbowych. Bezpieczne resetowanie kodu dostępu zastępuje resetPassword() tymi ulepszeniami:

DPC może zresetować kod dostępu, zanim użytkownik odblokuje urządzenie lub profil (po ponownym uruchomieniu urządzenia z szyfrowaniem opartym na plikach).
Magazyn kluczy Android przechowuje klucze uwierzytelnione przez użytkownika po zresetowaniu hasła.

Jeśli Twoja kompilacja DPC jest kierowana na Androida 8.0 (poziom interfejsu API 26) lub nowszego, używaj bezpiecznego resetowania kodu dostępu. Wywołanie resetPassword() powoduje wysłanie SecurityException w DPC kierowanych na Androida 8.0 lub nowszego, więc może być konieczne zaktualizowanie DPC.

Ustawianie i aktywowanie tokena

DPC musi ustawić i aktywować token, zanim zresetujesz hasło. Ponieważ kontroler DPC może nie być w stanie od razu użyć tokena, należy ustawić go z wyprzedzeniem na czas potrzebny administratorom IT.

Token resetowania hasła to silna kryptograficznie losowa wartość, która musi mieć co najmniej 32 bajty. Utwórz token dla każdego urządzenia i profilu – nie używaj ponownie ani nie udostępniaj wygenerowanych tokenów.

Zalecamy przechowywanie tokenów, czyli sposobów odszyfrowywania zaszyfrowanego tokena, na serwerze. Jeśli przechowujesz tokeny lokalnie w magazynie zaszyfrowanych danych logowania, DPC nie może zresetować hasła, dopóki użytkownik nie odblokuje urządzenia lub profilu. Jeśli przechowujesz tokeny lokalnie w szyfrowanej pamięci urządzenia, która została przejęta, osoba przeprowadzająca atak może wykorzystać token, aby uzyskać dostęp do profilu służbowego lub konta użytkownika głównego.

Możesz wygenerować nowy token w swojej DPC lub pobrać go z serwera. Przykład poniżej pokazuje, jak DPC samodzielnie generuje token i zgłasza go do serwera:

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);
}

W większości przypadków DPC musi aktywować token po jego skonfigurowaniu. Jeśli jednak użytkownik nie będzie miał hasła do ekranu blokady, system od razu aktywuje token. Aby aktywować token, poproś użytkownika o potwierdzenie danych logowania. DPC może wywołać metodę KeyguardManager createConfirmDeviceCredentialIntent(), aby uzyskać Intent, który rozpocznie potwierdzenie. W interfejsie urządzenia wyjaśnij użytkownikowi, dlaczego prosisz go o uwierzytelnienie. Fragment kodu poniżej pokazuje, jak możesz aktywować token na 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
}

Przed ponownym uruchomieniem urządzenia musisz aktywować token ustawiony przez DPC. Android przechowuje nieaktywowany token w pamięci i nie utrzymuje go po zrestartowaniu. Jeśli użytkownik zrestartuje urządzenie przed aktywacją tokena, DPC może ponownie ustawić ten sam token lub wygenerować nowy.

DPC może potwierdzić, że token jest aktywny, wywołując metodę isResetPasswordTokenActive() i sprawdzając wynik: true.

Gdy DPC ustawi i aktywuje token, będzie on ważny do momentu, gdy DPC go usunie lub zastąpi (albo nie przywróci na urządzeniu ustawień fabrycznych). Token jest niezależny od hasła i nie ma na niego wpływu zmiana ani wyczyszczenie hasła przez użytkownika.

Usuwanie tokena

Możesz wywołać clearResetPasswordToken(), aby usunąć token ustawiony wcześniej przez DPC. Konieczne może być unieważnienie przejętego tokena lub usunięcie możliwości resetowania hasła. Poniższy przykład pokazuje, jak to zrobić na 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 ...
}

Resetowanie hasła

Gdy administrator IT musi zresetować hasło, wywołaj metodę resetPasswordWithToken() i przekaż z wyprzedzeniem ustawiony i aktywowany przez Ciebie token DPC:

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.
}

Wywołanie resetPasswordWithToken() zwraca wartość false, a hasło nie zmienia się, jeśli nowe hasło nie spełnia tych ograniczeń:

Liczba znaków musi spełniać wymagania dotyczące minimalnej długości hasła. Wywołaj getPasswordMinimumLength(), aby sprawdzić, czy administrator IT ustawił ograniczenie długości.
Zakres i złożoność znaków w haśle podlegają ograniczeniom kompozycji. Wywołaj getPasswordQuality(), aby sprawdzić, czy administrator IT ustawił ograniczenie kompozycji.

Jeśli ograniczenia jakości haseł nie wymagają ustawienia hasła, możesz przekazać null lub pusty ciąg znaków do resetPasswordWithToken(), aby je usunąć.

Test zabezpieczający logowanie na profilu służbowym

DPC uruchomiony w trybie właściciela profilu może wymagać od użytkowników określenia testu zabezpieczającego dla aplikacji działających w profilu służbowym. System wyświetla test zabezpieczający, gdy użytkownik próbuje otworzyć dowolną aplikację służbową. Jeśli użytkownik ukończy test zabezpieczający, system odblokuje profil służbowy i w razie potrzeby odszyfruje go.

Jak działa test zabezpieczający logowanie w profilu służbowym

Jeśli DPC wysyła intencję ACTION_SET_NEW_PASSWORD, system prosi użytkownika o ustawienie testu zabezpieczającego.
DPC może też wysłać prośbę ACTION_SET_NEW_PARENT_PROFILE_PASSWORD, aby poprosić użytkownika o ustawienie blokady urządzenia.

DPC może ustawiać zasady dotyczące haseł na potrzeby testu zabezpieczającego inaczej niż zasady dla innych haseł na urządzeniach. Na przykład minimalna długość odpowiedzi na test zabezpieczający logowanie oparty na urządzeniu może różnić się od wymaganej w przypadku innych haseł. DPC ustawia zasady testów zabezpieczających za pomocą zwykłych metod DevicePolicyManager, takich jak setPasswordQuality() i setPasswordMinimumLength().

co należy wziąć pod uwagę

DPC może zresetować hasło do profilu służbowego, ale nie może zresetować hasła urządzenia (osobistego). Jeśli użytkownik zdecyduje się ustawić takie same hasła służbowe i osobiste, resetPassword() w profilu służbowym spowoduje zresetowanie hasła tylko w profilu służbowym, a zarazem inne niż na ekranie blokady urządzenia.
DPC może dostosować ekran z danymi logowania do zadania, używając setOrganizationColor() i setOrganizationName().
Administratorzy urządzeń nie mogą używać resetPassword() do czyszczenia haseł ani zmieniania haseł, które są już ustawione. Administratorzy urządzeń mogą ustawić hasło, ale tylko wtedy, gdy na urządzeniu nie ma hasła, kodu PIN ani wzoru.

Więcej informacji znajdziesz w artykule getParentProfileInstance() oraz dokumentacji referencyjnej DevicePolicyManager.