רישום וניהול של מכשיר

הקצאת הרשאות היא תהליך ההגדרה של מכשיר לניהול באמצעות policies על ידי enterprise. במהלך התהליך, במכשיר מותקנת אפליקציית Android Device Policy, שמשמשת לקבלת policies ולאכיפתה. אם הקצאת המשאבים תתבצע בהצלחה, ה-API ייצור אובייקט devices, שיקשר את המכשיר לארגון.

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

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

Android מגרסה 5.1 ואילך

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

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

מכשירים בבעלות החברה לשימוש בעבודה ולשימוש אישי

Android מגרסה 8 ואילך

הגדרת מכשיר בבעלות החברה עם פרופיל עבודה מאפשרת להשתמש במכשיר גם לצורכי עבודה וגם למטרות אישיות. במכשירים שבבעלות החברה עם פרופילי עבודה:

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

מכשירים בבעלות החברה לשימוש עסקי בלבד

Android מגרסה 5.1 ואילך

ניהול מלא של המכשיר מתאים למכשירים שבבעלות החברה, שנועדו למטרות עבודה בלבד. ארגונים יכולים לנהל את כל האפליקציות במכשיר ולאכוף את כל הפקודות והמדיניות של Android Management API.

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

כדי להגדיר ניהול מלא במכשיר בבעלות החברה, יוצרים אסימון הרשמה, מוודאים שהערך של allowPersonalUsage מוגדר ל-PERSONAL_USAGE_DISALLOWED או ל-PERSONAL_USAGE_DISALLOWED_USERLESS, ומשתמשים באחת משיטות הקצאת המשאבים הבאות.

כללי מדיניות יכולים להשפיע על היצירה של ממשק המשתמש במהלך הקצאת המכשיר. כללי המדיניות האלה הם:

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


יצירת טוקן רישום

סקירה כללית על Android Management.
איור 1. יוצרים אסימון שרושם את המדיניות 'policy1' למכשירים ומחילה אותה עליהם. תוקף האסימון יפוג אחרי 1,800 שניות (30 דקות).

צריך אסימון הרשמה לכל מכשיר שרוצים לרשום (אפשר להשתמש באותו אסימון בכמה מכשירים). כדי לבקש אסימון הרשמה, צריך להתקשר למספר enterprises.enrollmentTokens.create. כברירת מחדל, התוקף של אסימוני ההרשמה פג אחרי שעה אחת, אבל אפשר לציין מועד תפוגה מותאם אישית (duration) של עד כ-10,000 שנים.

בקשה מוצלחת מחזירה אובייקט enrollmentToken שמכיל enrollmentTokenId ו-qrcode, שבהם מנהלי IT ומשתמשי קצה יכולים להשתמש כדי להקצות מכשירים.

ציון מדיניות

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

ציון שימוש אישי

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


מידע על קודי QR

קודי QR משמשים כשיטה יעילה להקצאת מכשירי לארגונים שמנהלים הרבה מדיניות שונה. קוד ה-QR שמוחזר מ-enterprises.enrollmentTokens.create מורכב ממטען שימושי של צמדי מפתח/ערך שמכילים טוקן הרשמה וכל המידע שנחוץ ל-Android Device Policy כדי להקצות מכשיר.

חבילת קודי QR לדוגמה

החבילה כוללת את מיקום ההורדה של Android Device Policy ואת אסימון ההרשמה.

{
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup",
    "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
        "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "{enrollment-token}"
    }
}

אפשר להשתמש בקוד ה-QR שמוחזר מ-enterprises.enrollmentTokens.create ישירות או להתאים אותו אישית. ביצירת קוד QR מפורטת רשימה מלאה של המאפיינים שאפשר לכלול בחבילת קוד QR.

כדי להמיר את המחרוזת qrcode לקוד QR שאפשר לסרוק, משתמשים בתוכנה ליצירת קודי QR כמו ZXing.


שיטות הקצאה

בקטע הזה מתוארות שיטות שונות להקצאת מכשיר.

הוספת פרופיל עבודה מה'הגדרות'

Android מגרסה 5.1 ואילך

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

  1. עוברים אל הגדרות > Google > הגדרה ושחזור.
  2. מקישים על הגדרת פרופיל העבודה.

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

הורדת Device Policy ל-Android

Android מגרסה 5.1 ואילך

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

Android מגרסה 5.1 ואילך

באמצעות אסימון ההרשמה שהוחזר מ-enrollmentTokens.create או מ-signinEnrollmentToken של הארגון, יוצרים כתובת URL בפורמט הבא:

https://enterprise.google.com/android/enroll?et=<enrollmentToken>

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

כתובת URL לכניסה

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

  1. מציינים את כתובת ה-URL לכניסה ב-enterprises.signInDetails[]. מגדירים את הערך של allowPersonalUsage ל-PERSONAL_USAGE_ALLOWED אם רוצים לאפשר למשתמש ליצור פרופיל עבודה (חובה במכשירים בבעלות אישית, אופציונלי במכשירים בבעלות החברה).

    מוסיפים את הערך של signinEnrollmentToken כפריט Provisioning Extra לקוד QR, למטען שימושי של NFC או להגדרה ללא מגע. לחלופין, אפשר לספק את הערך של signinEnrollmentToken למשתמשים ישירות.

  2. בוחרים אפשרות:

    1. מכשירים בבעלות החברה: אחרי שמפעילים מכשיר חדש או מכשיר שבו בוצע איפוס להגדרות המקוריות, מעבירים את signinEnrollmentToken למכשיר (באמצעות קוד QR, התנגשות NFC וכו') או מבקשים מהמשתמשים להזין את האסימון באופן ידני. במכשיר תוצג כתובת ה-URL לכניסה שצוינה בשלב 1.
    2. מכשירים בבעלות אישית: מבקשים מהמשתמשים להוסיף פרופיל עבודה מה'הגדרות'. כשמוצגת בקשה, המשתמש סורק קוד QR שמכיל את signinEnrollmentToken או מזין את האסימון באופן ידני. במכשיר תיפתח כתובת ה-URL לכניסה שצוינה בשלב 1.
    3. מכשירים בבעלות אישית: מספקים למשתמשים קישור לטוקן ההרשמה, שבו טוקן ההרשמה הוא signinEnrollmentToken. במכשיר תיפתח כתובת ה-URL לכניסה שצוינה בשלב 1.
  3. בודקים אם Google כבר אימתה את המשתמש. מקבלים את פרטי ההקצאה של המכשיר (במהלך הרשמת המכשיר) באמצעות הפרמטר GET‏ provisioningInfo ובודקים אם יש ערך בשדה authenticatedUserEmail. אם יש ערך בשדה הזה, סימן שהמשתמש כבר אומת על ידי Google ואפשר להשתמש בזהות הזו בלי אימות נוסף.

  4. אם Google עדיין לא אימתה את המשתמש, כתובת ה-URL לכניסה צריכה לבקש מהמשתמשים להזין את פרטי הכניסה שלהם. על סמך הזהות שלהם, תוכלו לקבוע את המדיניות המתאימה ולקבל את פרטי הקצאת המכשיר (במהלך ההרשמה של המכשיר) באמצעות הפרמטר GET‏ provisioningInfo.

  5. קוראים ל-enrollmentTokens.create ומציינים את policyId המתאים על סמך פרטי הכניסה של המשתמש.

  6. מחזירים את אסימון ההרשמה שנוצר בשלב 5 באמצעות הפניה אוטומטית לכתובת URL, בטופס https://enterprise.google.com/android/enroll?et=<token>.

שיטת קוד QR

Android מגרסה 7.0 ואילך

כדי להקצות מכשיר בבעלות החברה, אפשר ליצור קוד QR ולהציג אותו במסוף ה-EMM:

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

שיטת NFC

Android 6.0 ואילך

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

הנחיות מפורטות לגבי תמיכה בשיטת ה-NFC זמינות במסמכי התיעוד למפתחים של Play EMM API. באתר יש גם קוד לדוגמה של הפרמטרים שמוגדרים כברירת מחדל, שמועברים למכשיר באמצעות מגע NFC. כדי להתקין את 'Device Policy למכשירי Android', מגדירים את מיקום ההורדה של חבילת האדמין של המכשיר כך:

https://play.google.com/managed/downloadManagingApp?identifier=setup

שיטת המזהה של DPC

אם אי אפשר להוסיף את Android Device Policy באמצעות קוד QR או NFC, משתמש או אדמין IT יכולים לפעול לפי השלבים הבאים כדי להקצות מכשיר בבעלות החברה:

  1. פועלים לפי מדריך ההגדרה במכשיר חדש או במכשיר שבו בוצע איפוס להגדרות המקוריות.
  2. מזינים את פרטי הכניסה ל-Wi-Fi כדי לחבר את המכשיר לאינטרנט.
  3. כשמתבקשים להיכנס, מזינים afw#setup כדי להוריד את מדיניות המכשיר של Android.
  4. כדי להקצות את המכשיר, סורקים קוד QR או מזינים ידנית את אסימון ההרשמה.

הרשמה דרך הארגון

Android מגרסה 8.0 ואילך (Pixel מגרסה 7.1 ואילך)

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

ארגונים יכולים ליצור הגדרות אישיות שמכילות פרטי הקצאה למכשירים שלהם בהרשמה דרך הארגון, דרך פורטל ההרשמה דרך הארגון או באמצעות מסוף ה-EMM (ראו zero-touch customer API). בהפעלה הראשונה, מכשיר ללא מגע בודק אם הוקצה לו תצורה. אם כן, המכשיר יוריד את Android Device Policy, שתשלים את הגדרת המכשיר באמצעות הפריטים הנוספים להקצאה שצוינו בהגדרה שהוקצה לו.

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

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

{
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":"I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
   "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
      "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"{Sign In URL token}"
   }
}

הפעלת אפליקציה במהלך ההגדרה

setupaction
איור 2. להשתמש ב-setupActions כדי להפעיל אפליקציה במהלך ההגדרה.

בשדה policies אפשר לציין אפליקציה אחת ש-Android Device Policy תפעיל במהלך ההגדרה של המכשיר או פרופיל העבודה. לדוגמה, אפשר להפעיל אפליקציית VPN כדי שהמשתמשים יוכלו להגדיר את הגדרות ה-VPN כחלק מתהליך ההגדרה. האפליקציה צריכה להחזיר את הערך RESULT_OK כדי לסמן שהיא הושלמה ולאפשר ל-Android Device Policy להשלים את הקצאת המכשיר או פרופיל העבודה. כדי להפעיל אפליקציה במהלך ההגדרה:

מוודאים שהערך של installType באפליקציה הוא REQUIRED_FOR_SETUP. אם לא ניתן להתקין את האפליקציה או להפעיל אותה במכשיר, ההקצאה תיכשל.

{
   "applications":[
      {
         "packageName":"com.my.vpnapp.",
         "installType":"REQUIRED_FOR_SETUP"
      }
   ]
}

מוסיפים את שם החבילה של האפליקציה אל setupActions. משתמשים ב-title וב-description כדי לציין הוראות שמוצגות למשתמש.

{
   "setupActions":[
      {
         "title":{
            "defaultMessage":"Configure VPN"
         },
         "description":{
            "defaultMessage":"Enable your VPN client to access corporate resources."
         },
         "launchApp":{
            "packageName":"com.my.vpnapp."
         }
      }
   ]
}

כדי להבדיל בין אפליקציה שמופעלת מ-launchApp לבין אפליקציה שמופעלת על ידי משתמש, הפעילות שמופעלת לראשונה כחלק מהאפליקציה מכילה את הרכיב הנוסף של הכוונה הבוליאנרית com.google.android.apps.work.clouddpc.EXTRA_LAUNCHED_AS_SETUP_ACTION (שמוגדר לערך true). הרכיב הנוסף הזה מאפשר להתאים אישית את האפליקציה בהתאם לגורם שהפעיל אותה – setupActions או משתמש.

אחרי שהאפליקציה מחזירה את הערך RESULT_OK, אפליקציית Android Device Policy משלימה את כל השלבים שנותרו כדי להקצות את המכשיר או את פרופיל העבודה.

ביטול ההרשמה במהלך ההגדרה

האפליקציה שפועלת כ-SetupAction יכולה לבטל את ההרשמה ולהחזיר את הערך RESULT_FIRST_USER.

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

הערה: ביטול ההרשמה מפעיל את הפעולה בלי תיבת דו-שיח לאישור המשתמש. האפליקציה אחראית להציג למשתמש תיבת דו-שיח מתאימה עם הודעת שגיאה לפני שהיא מחזירה את הערך RESULT_FIRST_USER.

החלת מדיניות על מכשירים שנרשמו לאחרונה

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

  • (מומלץ) כשיוצרים אסימון הרשמה, אפשר לציין את שם המדיניות (policyName) שתקושר במקור למכשיר. כשרושמים מכשיר באמצעות הטוקן, המדיניות חלה על המכשיר באופן אוטומטי.

  • הגדרת מדיניות כמדיניות ברירת המחדל לארגון. אם לא צוין שם של מדיניות באסימון ההרשמה וקיימת מדיניות בשם enterprises/<enterprise_id>/policies/default, כל מכשיר חדש מקושר באופן אוטומטי למדיניות ברירת המחדל בזמן ההרשמה.

  • להירשם לנושא Cloud Pub/Sub כדי לקבל התראות על מכשירים חדשים שנרשמו. בתגובה להתראה ENROLLMENT, צריך לבצע קריאה ל-enterprises.devices.patch כדי לקשר את המכשיר למדיניות.

רישום מכשיר ללא מדיניות

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

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

דוגמה לתהליך עבודה לבדיקת רישוי

  1. מכשיר רשום ללא מדיניות ברירת מחדל או מדיניות ספציפית.
  2. בודקים כמה רישיונות נותרו לארגון.
  3. אם יש רישיונות זמינים, משתמשים ב-devices.patch כדי לצרף מדיניות למכשיר, ואז מפחיתים את מספר הרישיונות. אם אין רישיונות זמינים, משביתים את המכשיר באמצעות devices.patch. לחלופין, ה-API מאפס להגדרות המקוריות כל מכשיר שלא מצורף למדיניות תוך חמש דקות מרגע הרישום.