אבטחה

התכונות במדריך הזה מתארות את היכולות של ניהול האבטחה שאתם יכולים להשתמש בהן להטמיע באפליקציה בקר מדיניות מכשירים (DPC). המסמך הזה שמכיל דוגמאות קוד, ואפשר גם להשתמש באפליקציה בדיקת DPC בתור מקור של קוד לדוגמה לתכונות הארגוניות של Android.

אפליקציית DPC יכולה לפעול במצב 'בעלי הפרופיל' במכשירים אישיים או אצל בעלי המכשיר במכשירים מנוהלים. בטבלה הזו מצוין אילו תכונות זמינות כשה-DPC פועל במצב בעלי הפרופיל או במצב בעלי המכשיר:

להשבית את הגישה לאפליקציות

לארגונים שרוצים לחסום לעובדים את האפשרות לשחק או לצפות במשחקים YouTube במכשירים מבוססי-Android שלהם בשעות מסוימות במהלך היום, או בימים מסוימים בשבוע, בקר DPC יכול להשבית באופן זמני את הגישה לאפליקציות.

כדי להשבית את הגישה לאפליקציות, בקר DPC שפועל במצב 'בעלי המכשיר או בעלי הפרופיל' מגדיר את setPackagesSuspended(), ואז האפליקציה שנבחרה תפעל כאילו היא מושבתת (מרכז האפליקציות של Google מופיע באפור). כשמשתמש מקיש על האפליקציה, הם רואים תיבת דו-שיח של המערכת שאומרת שהאפליקציה מושעית.

בזמן שאפליקציה מושעית, היא לא יכולה להתחיל פעילויות ולקבל התראות החבילות מבוטלות. חבילות מושעות לא מופיעות בסקירה הכללית מסך, לא ניתן להציג בהם תיבות דו-שיח (כולל טוסטים וחטיפים), לא ניתן להשמיע אודיו או לרטוט את המכשיר.

מרכזי אפליקציות יכולים לגלות אם אפליקציה מושעית באמצעות קריאה isPackageSuspended(). לפרטים על הגדרת האפליקציה לגבי השעיה, ראה setPackagesSuspended.

חסימת אפליקציות ממקורות לא מוכרים

אפליקציות שלא מותקנות מ-Google Play (או מחנויות אפליקציות מהימנות אחרות) שנקראו אפליקציות ממקורות לא ידועים. מכשירים ונתונים עלולים להיות בסיכון גבוה יותר כשאנשים מתקינים את האפליקציות האלה.

כדי למנוע מאנשים להתקין אפליקציות ממקורות לא מוכרים, רכיבי הניהול של במכשירים שמנוהלים באופן מלא, ופרופילים של עבודה יכולים להוסיף DISALLOW_INSTALL_UNKNOWN_SOURCES הגבלת משתמשים.

הגבלה ברמת המכשיר בפרופיל העבודה

כשהאדמין של פרופיל עבודה מוסיף DISALLOW_INSTALL_UNKNOWN_SOURCES, ההגבלה חלה רק על פרופיל העבודה. עם זאת, האדמין של עבודה יכול להגביל אותו ברמת המכשיר באמצעות הגדרה של הגדרות אישיות מנוהלות ל-Google Play. ההגבלה על כל המכשיר היא זמינה ב-Android מגרסה 8.0 (ואילך) כשאפליקציית Google Play שמותקנת במכשיר מגרסה 80812500 ואילך.

כדי להגביל התקנות של אפליקציות ל-Google Play, מבצעים את השלבים הבאים:

1. הגדרת חבילת הגדרות מנוהלות עבור חבילת Google Play com.android.vending
2. בחבילה, שם ערך בוליאני עבור מקש verify_apps:device_wide_unknown_source_block.
3. מוסיפים את הגבלת המשתמשים ב-ENSURE_VERIFY_APPS.

בדוגמה הבאה אפשר לראות איך אפשר לבדוק אם מערכת Google Play תומכת בכך ומגדירים את הערך כ-true:

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)

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

ממשק המשתמש בהגדרות המערכת נשאר פעיל אבל המערכת חוסמת התקנת האפליקציה. ההגבלה הזו משפיעה על התקנות עתידיות – בעבר האפליקציות המותקנות יישארו במכשיר. המשתמשים במכשיר יכולים להמשיך להתקין אפליקציות בפרופיל האישי באמצעות Android Debug Bridge (adb).

למידע נוסף על מקורות לא ידועים, אפשר לקרוא את המאמר הפצה חלופית הפרמטר הזה.

הגבלת חשבונות ב-Google Play

לפעמים בארגון רוצים לאפשר לאנשים להוסיף חשבונות Google אישיים חשבונות (לדוגמה, לקריאת אימייל ב-Gmail) אבל לא רוצה את החשבון האישי כדי להתקין אפליקציות. בקר ה-DPC יכול להגדיר רשימה של חשבונות שבהם אנשים יכולים להשתמש Google Play.

רכיבי ניהול של מכשירים מנוהלים או של פרופילי עבודה יכולים להגביל חשבונות על ידי הגדרה של תצורה מנוהלת ל-Google Play. החשבון ההגבלה זמינה כשאפליקציית Google Play שמותקנת במכשיר היא בגרסה 80970100 ומעלה.

כדי להגביל את החשבונות ב-Google Play, יש לבצע את הפעולות הבאות:

1. הגדרת חבילת הגדרות מנוהלות עבור חבילת Google Play com.android.vending
2. בחבילה, צריך לשמור את כתובות האימייל שמופרדות בפסיקים כערך מחרוזת עבור מקש allowed_accounts.

בדוגמה הבאה אפשר לראות איך מגבילים חשבונות:

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)

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

כדי להגביל את Google Play לחשבון לצורכי עבודה בלבד, צריך להגדיר את allowed_accounts לערך חשבון מנוהל יחיד ברגע שה-DPC יודע את כתובת האימייל של החשבון. מחרוזת ריקה מונעת מאנשים להשתמש בכל חשבון ב-Google Play.

הפעלת ההגנה מפני איפוס להגדרות המקוריות של הארגון

בעזרת התכונה 'הגנה מפני איפוס להגדרות המקוריות', ארגונים יכולים להגדיר באמצעות חשבונות Google אפשר להקצות מכשיר שעבר איפוס להגדרות המקוריות.

ההגנה של הצרכן איפוס להגדרות המקוריות נועדה להרתיע גניבת מכשיר. לפני לאפשר לכל אחד להקצות את המכשיר לאחר איפוס לא מורשה להגדרות המקוריות (למשל כמו בשימוש ב-EMM), אשף ההגדרה דורש מהמשתמש לבצע אימות מול חשבונות Google שהיו מוגדרים בעבר בפרופיל האישי של המכשיר.

בסביבה ארגונית, איפוס להגדרות המקוריות הוא כלי חשוב לניהול מכשירים של עובדים כאשר עובד עוזב את הארגון. אבל אם הארגון לא יודע את פרטי הכניסה לחשבון של עובד, איפוס להגדרות המקוריות ההגנה עלולה לחסום את היכולת של הארגון להנפיק מכשיר לאחר עובד.

שליטה על ניהול התצורה לאחר איפוס להגדרות המקוריות

כשמפעילים את המכשיר במצב 'בעלי המכשיר', ה-DPC יכול להשתמש setFactoryResetProtectionPolicy() כדי לקבוע אילו חשבונות מורשה להקצות מכשיר לאחר איפוס להגדרות המקוריות. אם ההגדרה הזו מוגדר ל-null או מוגדר כרשימה ריקה, החשבונות שמורשים להקצות במכשיר לאחר איפוס להגדרות המקוריות הם החשבונות בפרופיל האישי של במכשיר.

בקר DPC יכול להגדיר את החשבונות האלה במהלך כל משך החיים של שרת מנוהל במכשיר.

1. אדמין ב-IT יכול להשתמש בשיטה people.get מ-People API עם הערך המיוחד me. הפעולה הזו מאחזרת את ה-userId של שמחובר לחשבון. הערך userID מוחזר במפתח resourceName ב בצורה people/[userId] כמחרוזת של מספר שלם. יכול להיות שהחשבונות החדשים ייווצרו לא יהיו זמינים למטרות איפוס להגדרות המקוריות במשך 72 שעות.
2. מומלץ גם לאפשר למנהל IT אחד או יותר לבטל את נעילת המכשיר לאחר איפוס להגדרות המקוריות. לבקש מכל אחד מהאדמינים ב-IT להתחבר לחשבון Google שלהם גם לבצע את שלב 1 ולשתף את הuserId שלו איתך כדי שניתן יהיה להוסיף אותם userIds לרשימה בשלב הבא.
3. בקר ה-DPC מגדיר הגבלה מתאימה לאפליקציה באמצעות setFactoryResetProtectionPolicy() כדי להגדיר את הרשימה של userId שיכול להקצות מכשיר לאיפוס להגדרות המקוריות.
4. בקר ה-DPC מאפשר חשבונות שיכולים להקצות מכשירים לאחר הפעלת מפעל אופסו על ידי שליחת השידור com.google.android.gms.auth.FRP_CONFIG_CHANGED ככוונה מפורשת למנוע הסרה בגלל הגבלות ברקע.

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)

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

הדור הקודם

למכשירים שלא יכולים להשתמש ב-setFactoryResetProtectionPolicy(), הושק עם API ברמה 30, בקר ה-DPC יכול להשתמש ב-setApplicationRestrictions כדי להוסיף החשבונות שנבחרו להגדרה המנוהלת factoryResetProtectionAdmin לחבילת com.google.android.gms.

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)

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

השבתת ההגנה מפני איפוס להגדרות המקוריות של הארגון

כדי להשבית את ההגנה מפני איפוס להגדרות המקוריות, ה-DPC יכול להשתמש setFactoryResetProtectionPolicy()העברת הערך null.

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)

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

הדור הקודם

למכשירים שלא יכולים להשתמש ב-setFactoryResetProtectionPolicy(), הושק עם API ברמה 30, בקר ה-DPC יכול להשתמש ב-setApplicationRestrictions כדי להגדיר מפתח הערך של true ב-disableFactoryResetProtectionAdmin המנוהל עבור החבילה com.google.android.gms.

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)

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

מעקב אחרי יומני תהליכים ודוחות מרחוק על באגים

במסוף ה-EMM, אדמין יכול לעקוב אחרי מכשירים מנוהלים באמצעות הארגון לעבד יומנים ודוחות מרוחקים על באגים.

רישום פעילות במכשירים ארגוניים

בקר DPC שפועל במצב 'בעלי המכשיר' יכול לזהות פעילות חשודה מרחוק מעקב אחר פעילות במכשיר, כולל השקות של אפליקציות, Android Debug Bridge (adb) פעילות, וביטול נעילת המסך. יומני תהליכים לא מחייבים את הסכמת המשתמשים.

כדי להפעיל או להשבית רישום ביומן, בקר DPC מבצע קריאה setSecurityLoggingEnabled().

כשקבוצה חדשה של יומנים זמינה, DeviceAdminReceiver מקבל את קריאה חוזרת (callback) של onSecurityLogsAvailable(). כדי לאחזר את היומנים (אחרי מקבל את הקריאה החוזרת), בקר DPC מבצע קריאה retrieveSecurityLogs().

בקרי DPC יכולים גם להפעיל את הפונקציה retrievePreRebootSecurityLogs() כדי לאחזר את האבטחה יומנים שנוצרו במחזור האתחול הקודם. זהו המרווח שבין את ההפעלה האחרונה של המכשיר ואת האתחול לפני כן. מכשירים שלא תומכים הפונקציה retrieveSecurityLogs() מחזירה null. אם האפליקציה מאחזרת יומנים באמצעות retrievePreRebootSecurityLogs() וגם retrieveSecurityLogs(), עליך לבדוק אם יש רשומות כפולות.
הערה: התכונה הזו מתעדת פעילות רק במכשירים מנוהלים שכוללים רק משתמש או משתמשים משויכים במכשיר. התכונה הזו לא פועלת במכשירים אישיים, כי מתועדת בו פעילות ברמת המכשיר.

ההגדרה הזו יכולה להיות שימושית בבדיקה לאחר אירועי אבטחה, כי היא רושמת ביומן את את סוגי הפעולות הבאים:

• בכל פעם שהאפליקציה מופעלת מחדש. זה יכול לעזור לזהות אם יש תוכנה זדונית שמתחילה באפליקציה שנחשפה.
• ניסיונות לביטול נעילה שנכשלו במכשיר. הוא יכול לזהות אם יש כמה ניסיונות כושלים לביטול הנעילה בפרק זמן קצר.
• פקודות adb שעלולות להזיק כאשר משתמש מתחבר את המכשיר למחשב באמצעות כבל USB.

למידע נוסף על קריאת יומנים, ראו SecurityLog.

במהלך הפיתוח והבדיקה, אפשר לאלץ את המערכת לבצע יומני אבטחה קיימים שזמינים לבקר ה-DPC שלכם - לא צריך להמתין אצווה. ב-Android 9.0 (רמת API 28) ואילך, מריצים את הפקודה הבאה פקודת Android Debug Bridge (adb) בטרמינל:

adb shell dpm force-security-logs

המערכת מגבילה את תדירות השימוש בכלי ומדווחת על כל האטה מכוונת בפלט הטרמינל. אם יש יומנים זמינים, DPC מקבל את הקריאה החוזרת (callback) של onSecurityLogsAvailable().

בקשה מרחוק לדוח על באג

בקר DPC שפועל במצב 'בעלי המכשיר' יכול לבקש מרחוק דוחות על באגים עבור המשתמש מכשירים עם משתמש אחד בלבד או משתמשים משויכים אחד. דוח איתור הבאגים מתעד פעילות המכשיר בדיוק ברגע שבו התבקשת על הדוח על הבאג, אבל הוא עשוי גם לכלול פעילות מהשעות האחרונות, בהתאם לתדירות ה-Logcat של מאגר הנתונים הזמני.

כדי לבקש דוחות על באגים מרחוק, בקר ה-DPC מבצע קריאה אל requestBugreport():

• אם המשתמש יאשר את השיתוף של דוח איתור הבאגים, ה-DPC יקבל את הבאג דיווח באמצעות onBugreportShared()
• אם המשתמש מסרב לשתף את דוח הבאג, ה-DPC מקבל שיתוף בקשה נדחתה באמצעות onBugreportSharingDeclined()
• אם דוח על באג נכשל, בקר ה-DPC רואה את הערך onBugreportFailed() עם BUGREPORT_FAILURE_FAILED_COMPLETING או BUGREPORT_FAILURE_FILE_NO_LONGER_AVAILABLE.

הענקת גישה והסרת גישה לאישור לקוח

אם בקר DPC שפועל במצב 'בעלי הפרופיל' או 'בעלי המכשיר' מעניק גישה לאפליקציה של צד שלישי יכולת לנהל אישורים, האפליקציה יכולה להעניק לעצמה גישה אל אישורים שהוא מתקין ללא התערבות של המשתמש. כדי להתקין אישור שכל האפליקציות בפרופיל יכולות לגשת אליו, צריך להשתמש ב-installKeyPair().

אילו פרמטרים להגדיר, ראו installKeyPair(). התכונה הזו פועל בשילוב עם ממשק ה-API הקיים לניהול אישורים.

תרחיש פריסה

בלי השיטה installKeyPair():

• המשתמשים צריכים להקיש על שם האישור ואז על אישור בכל פעם הוא רוצה להעניק גישה לאישור.
• המשתמשים רואים הודעה כשהם מתקינים אישור וצריכים לתת שם אישור.

באמצעות השיטה installKeyPair():

• המשתמשים לא צריכים להקיש על אישור בכל פעם שהם רוצים להעניק גישה אישור.
• המשתמשים לא יכולים לשנות את השם של האישורים.
• לאדמינים יש שליטה רבה יותר בכך שהם יכולים לחסום אישורים עבור אפליקציות שלא צריכה להיות להן גישה לאישורים ספציפיים.

הסרת אישור לקוח

לאחר הענקת גישה לאישור לקוח, כדי להסיר מרחוק את הלקוח אישורים שהותקנו דרך installKeyPair(), התקשרות removeKeyPair()

בקר DPC שפועל במצב 'בעלי המכשיר' או במצב 'בעלי הפרופיל', או שהוענקה לך גישה אליו מתקין האישורים יכול לקרוא ל-removeKeyPair(). הפעולה הזו מסירה לאישור ולזוג מפתחות פרטיים שמותקנים תחת כינוי נתון של מפתח פרטי.

תרחיש פריסה

יש להשתמש בתכונה הזו אם ארגון עובר לצורה מאובטחת יותר של לקוח אישור. אם אדמין משיק אישור חדש, ואת ההפצה שלו לוקח זמן רב, האדמין יכול לבטל אחרי שההעברה תסתיים.

איפוס קוד הגישה המאובטח

בקר ה-DPC יכול לאפס סיסמה של משתמש על ידי אישור השינוי באמצעות אסימון מאובטח שנרשם מראש. בעלי המכשיר ובעלי הפרופילים יכולים להתקשר למאובטח ממשקי API לאיפוס סיסמה כדי לשנות את הסיסמה של המכשירים ושל הפרופילים של העבודה בהתאמה. איפוס של קוד הגישה המאובטח מחליף את resetPassword() ב- השיפורים הבאים:

• בקר ה-DPC יכול לאפס את קוד הגישה לפני שהמשתמש מבטל את נעילת המכשיר או הפרופיל לאחר הפעלה מחדש במכשירים שמשתמשים הצפנה מבוססת-קבצים.
• ב-Android Keystore נשמרים מפתחות שאומתו על ידי המשתמשים לאחר איפוס של קוד הגישה.

אם גרסת ה-build של בקר ה-DPC מיועדת ל-Android 8.0 (API), צריך לאפס את קוד הגישה המאובטח רמה 26) ומעלה. אם מתקשרים אל resetPassword(), מקבלים SecurityException בבקרי DPC שמטרגטים ל-Android 8.0 ואילך, צריך לעדכן את ה-DPC.

הגדרה והפעלה של אסימון

צריך להגדיר אסימון ולהפעיל אותו ב-DPC לפני איפוס סיסמה. כי ייתכן שה-DPC לא יוכל להשתמש באסימון באופן מיידי, מראש שאולי מנהל ב-IT יצטרך להשתמש בו.

אסימון לאיפוס סיסמה הוא ערך אקראי חזק מבחינה קריפטוגרפית והוא צריך להיות באורך של 32 בייטים לפחות. יוצרים אסימון לכל מכשיר ופרופיל – לעשות שימוש חוזר באסימונים שנוצרו או לשתף אותם.

אנחנו ממליצים לשמור אסימונים או את האמצעים לפענוח אסימון מוצפן השרת. אם אתם מאחסנים אסימונים באופן מקומי באחסון מוצפן באמצעות פרטי כניסה, ה-DPC לא ניתן לאפס את הסיסמה עד שהמשתמש יבטל את הנעילה של המכשיר או הפרופיל. אם לאחסן את האסימונים באופן מקומי באחסון מוצפן במכשיר, שנפרץ, תוקף עלול להשתמש באסימון כדי לקבל גישה לפרופיל עבודה או משתמש.

אפשר ליצור אסימון חדש ב-DPC או לאחזר אסימון משרת. הדוגמה הבאה מציגה בקר DPC שיוצר אסימון בעצמו ומדווח עליו שרת:

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

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

ברוב המקרים, בקר ה-DPC צריך להפעיל אסימון לאחר הגדרתו. אבל, כאשר למשתמש אין סיסמה למסך הנעילה, המערכת מפעילה אסימון ישירות. כדי להפעיל אסימון, צריך לבקש מהמשתמש לאשר את פרטי הכניסה שלו. בקר ה-DPC יכול לקרוא ל-method KeyguardManager createConfirmDeviceCredentialIntent() כדי לקבל Intent שמתחיל את אישור. הסבירו למשתמש במכשיר בממשק המשתמש, למה אתם ולבקש מהם לבצע אימות. קטע הקוד הבא מראה איך אפשר להפעיל בבקר ה-DPC:

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

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

צריך להפעיל אסימון שבקר ה-DPC מגדיר לפני שהמכשיר יופעל מחדש. במכשירי Android שומר אסימון שלא הופעל בזיכרון ולא שומר את האסימון אחרי להפעיל מחדש. אם המשתמש יפעיל מחדש את המכשיר לפני הפעלת אסימון, בקר ה-DPC להגדיר שוב את אותו אסימון או ליצור אסימון חדש.

ה-DPC יכול לאשר שאסימון פעיל באמצעות קריאה isResetPasswordTokenActive() ובדיקת התוצאה היא true.

לאחר שבקר ה-DPC מגדיר ומפעיל אסימון, הוא בתוקף עד שבקר ה-DPC נמחק או מחליפה את האסימון (או שהמכשיר מאופס להגדרות המקוריות). האסימון לא תלוי ב- הסיסמה ולא מושפעת משינוי או מחיקת הסיסמה על ידי המשתמש.

מחיקת אסימון

אפשר להתקשר אל clearResetPasswordToken() כדי למחוק אסימון שה-DPC שלך שהגדרתם קודם. יכול להיות שתצטרכו לבטל אסימון שנחשף, או שתרצו להסיר את האפשרות לאפס את הסיסמה. הדוגמה הבאה מראה איך אפשר לבצע את הפעולות הבאות הבאה בבקר ה-DPC:

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

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

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

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

איפוס הסיסמה

אם אדמין ב-IT צריך לאפס את הסיסמה, אפשר להתקשר resetPasswordWithToken() ומעבירים את האסימון שה-DPC הגדיר והופעל מראש:

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

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

קריאה אל resetPasswordWithToken() מחזירה false, והסיסמה לא כשהסיסמה החדשה לא עומדת במגבלות הבאות:

• מספר התווים תואם למגבלות של אורך סיסמה מינימלי. שיחת טלפון getPasswordMinimumLength() כדי לדעת אם צוות ה-IT האדמין הגדיר מגבלת אורך.
• הטווח והמורכבות של התווים בסיסמה יוצרים שילוב של קומפוזיציה אילוץ. התקשר אל getPasswordQuality() כדי לדעת אם צוות ה-IT האדמין הגדיר מגבלה על היצירה.

אם מגבלות האיכות של הסיסמה לא מחייבות הגדרה של סיסמה, אפשר להעביר את null או מחרוזת ריקה אל resetPasswordWithToken() כדי להסיר את סיסמה.

אתגר אבטחה של פרופיל העבודה

בקר DPC שפועל במצב 'בעלים של פרופיל' יכול לדרוש ממשתמשים לציין אבטחה אתגר לאפליקציות שפועלות בפרופיל העבודה. המערכת מציגה את רמת האבטחה כשהמשתמש מנסה לפתוח אפליקציות לעבודה. אם המשתמש הצליח משלים את אתגר האבטחה, המערכת מבטלת את הנעילה של פרופיל העבודה מפענח אותו, במקרה הצורך.

איך פועל אתגר האבטחה של פרופיל העבודה

1. אם בקר DPC שולח Intent מסוג ACTION_SET_NEW_PASSWORD, המערכת תבקש זאת את המשתמש להגדיר אתגר אבטחה.
2. ה-DPC יכול גם לשלוח ACTION_SET_NEW_PARENT_PROFILE_PASSWORD כוונה לבקש מהמשתמש להגדיר נעילת מכשיר.

בקר DPC יכול להגדיר את מדיניות הסיסמאות לאתגר העבודה באופן שונה כללי מדיניות לגבי סיסמאות למכשירים אחרים. לדוגמה, האורך המינימלי של התגובה לאתגר המכשיר יכולה להיות שונה מהאורך הנדרש סיסמאות. בקר DPC מגדיר את מדיניות האתגרים באמצעות השיטה הרגילה DevicePolicyManager, כמו setPasswordQuality() setPasswordMinimumLength().

שיקולים

• בקר ה-DPC יכול לאפס את הסיסמה בפרופיל העבודה, אבל לא יכול לאפס את הסיסמה (אישית) של המכשיר. אם משתמש בוחר להגדיר סיסמאות לצורכי עבודה וסיסמאות אישיות להיות זהה, אז resetPassword() בפרופיל העבודה גורם לאיפוס סיסמה בפרופיל העבודה בלבד, והסיסמה לא תהיה זהה בתור נעילת המסך של המכשיר.
• בקר DPC יכול להתאים אישית את מסך פרטי הכניסה לאתגר העבודה באמצעות הפקודה setOrganizationColor() והפקודה setOrganizationName().
• מנהלי מכשירים לא יכולים להשתמש ב-resetPassword() כדי למחוק סיסמאות או לשנות סיסמאות שכבר הוגדרו. מנהלי מכשירים עדיין יכולים להגדיר סיסמה, אבל רק כשהמכשיר לא כולל סיסמה, קוד אימות או קו ביטול נעילה.

לקבלת מידע נוסף, ראו getParentProfileInstance(). מסמכים בקטע DevicePolicyManager.