סיכום
במקור, Android הושקה עם תמיכה בניהול מכשירים ניידים ב-Android 2.2. מאז, הצרכים של ארגונים התפתחו כל הזמן. יותר ויותר מכשירים ניגשים למשאבים סודיים יותר, ונעשה בהם שימוש במגוון רחב יותר של תרחישי שימוש בהשוואה לממשק ה-API המקורי לניהול מכשירים של Android. ריכזנו כאן חלק מהתרחישים לדוגמה:
- הפרדה של נתוני עבודה ממידע אישי בשימוש מעורב או בפריסות BYOD.
- הפצת אפליקציות עסקיות וניהול הנתונים שלהן באמצעות Google Play וניהול חשבונות Google הנדרשים לכך.
- נעילת מכשירים בקיוסק כדי להתאים אותם לשימושים ספציפיים באפליקציות.
- ניהול אישורים כדי לאפשר גישה למשאבים מאובטחים מסוג PKI.
- הקמת רשתות VPN לפי אפליקציה ולפי פרופיל, כדי לתמוך באפליקציות ארגוניות מרחוק תוך הגנה על הפרטיות.
במקביל, ארגונים דרשו יחסי אמון גבוהים יותר מאלה שאדמין המכשיר נועד לתמוך בהם. מכיוון שאפשר להפעיל את האדמין של המכשיר באמצעות כל אפליקציה שהמשתמש מאשר, הוא לא תומך במספר תרחישים ארגוניים לדוגמה:
- להגדיר הגנה מפני איפוס להגדרות המקוריות (FRP) כדי לוודא שהמכשירים מנוהלים, ואפשר לשחזר אותם כשהעובדים עוזבים.
- איפוס מאובטח של סיסמאות למכשירים במכשירים מוצפנים.
- למנוע הסרה של מנהל המכשיר (הוסר ב-Nougat מטעמי אבטחה).
- הגדרת קודי גישה שהוגדרו על ידי מנהל מערכת לנעילת המשתמש מתוך מכשיר (הוסר ב-Android 7.0 Nougat מטעמי אבטחה).
ניהול מכשירים נחשב לגישת ניהול מדור קודם מאז ההשקה של המצבים המנוהלים של המכשיר (בעל המכשיר) ופרופיל העבודה (בעל הפרופיל) ב-Android 5.0. מאחר שאדמינים של מכשירים לא יכולים להתמודד עם דרישות הארגון של ימינו, אנחנו ממליצים ללקוחות ולשותפים להשתמש מעכשיו במצבי מכשיר מנוהלים ובמצב של פרופיל עבודה כדי לנהל את המכשירים שלהם מעכשיו והלאה. כדי לתמוך במעבר הזה ולמקד את המשאבים שלנו בתכונות הניהול הנוכחיות של Android, הוצאנו משימוש את התכונה 'ניהול מכשירים' לשימוש ארגוני בגרסה 9.0 של Android, ונסיר את הפונקציות האלה בגרסה 10.0 של Android.
כללי מדיניות שהוצאו משימוש
לאחר השקת Android 9.0, סעיפי המדיניות הבאים מסומנים כהוצאה משימוש בזמן הפעלה על ידי מנהל המכשיר, אבל ממשקי ה-API לא ימשיכו לפעול, מלבד זאת.
USES_POLICY_DISABLE_CAMERA
USES_POLICY_DISABLE_KEYGUARD_FEATURES
USES_POLICY_EXPIRE_PASSWORD
USES_POLICY_LIMIT_PASSWORD
החל מגרסה 10.0 של Android, כללי המדיניות שהוזכרו למעלה יגרמו ל-SecurityException
הפעלה של מנהל המכשיר באפליקציות שמטרגטות רמת API 29.
בגרסת Android 11.0, ה-USES_POLICY_RESET_PASSWORD
מסומן כ'הוצא משימוש' כשהוא מופעל על ידי מנהל המכשיר ומפסיק לפעול.
הקוד יסומן בכיתוב SecurityException
לאפליקציות שמטרגטות API ברמה 24 ומעלה.
אפליקציות מסוימות משתמשות במנהל המכשיר לניהול מכשירים של צרכנים, למשל נעילה ומחיקת מכשיר שאבד. כללי המדיניות הבאים ימשיכו להיות זמינים כדי לאפשר זאת:
עדכון ההטמעה
כדי להחליף את כללי המדיניות של מגן המקשים והסיסמה שמסומנים כהוצאה משימוש בקטע שלמעלה, אפליקציות – כולל אפליקציות שמנהלות פריסות של Exchange Gaming – צריכות להשתמש בשיטה המתוארת בבדיקת האיכות של נעילת המסך.
לוחות הזמנים
Android 9.0: ניהול המכשיר מסומן כהוצאה משימוש לשימוש ארגוני באמצעות עדכוני התיעוד. הפונקציונליות הקיימת ממשיכה לפעול באפליקציות שמטרגטות לרמת API 28, אבל לא מומלץ להשתמש בה. כל השותפים והלקוחות צריכים לעבור לפרופילי עבודה או למכשירים מנוהלים לפני השקת Android 10.0.
Android 10.0: המדיניות שלמעלה לא תהיה זמינה יותר לבקרי DPC שמטרגטים רמת API 29.
משמעות המדיניות מבחינת מנהלי IT
אנחנו ממליצים לשותפים וללקוחות להתחיל להתכונן לשינוי הזה כבר עכשיו. ניתן לזהות את השימוש של מנהל המכשיר במסך (לדוגמה, ראו איור 1), כשמפעילים את ניהול המכשיר:
![דוגמה להפעלת אדמין במכשיר](https://google-developers.gonglchuangl.net/static/android/work/images/activate-device-admin.png?authuser=1&hl=he)
אם אתם משתמשים כרגע בניהול מכשירים כדי לנהל את המכשירים, יש שתי אסטרטגיות זמינות להעברה לממשקי ה-API לניהול של Android הקיימים. כדי לרשום מכשיר לניהול, צריך להיות לכם ספק EMM (ניהול ניידות ארגונית) שתומך בפרופיל עבודה ב-Android (בעלי הפרופיל) או במצב מכשיר מנוהל (בעל המכשיר). הלקוחות צריכים לבחור את מצב הניהול שהכי מתאים לפריסה שלהם. במקרים מסוימים, ניתן להשתמש בשתי האסטרטגיות בו-זמנית.
כאן מופיעה רשימה של הצעות תואמות. ספק התוכנה לניהול הניידות בארגון יכול לספק הנחיות ספציפיות לגבי המוצרים שהוא מציע.
ניהול מכשירים אישיים (בבעלותך)
אפשר להשתמש במכשירים אישיים באמצעות מצב פרופיל העבודה ב-Android. פרופיל העבודה נפרס על ידי ספק EMM כדי לספק קונטיינר ברמת מערכת ההפעלה שמאפשר הפרדה בין אפליקציות העבודה של המשתמש לבין אפליקציות אישיות ונתונים במכשירים שלו. ארגונים נהנים מהיכולת לפרוס אפליקציות באמצעות Google Play לארגונים, וכך ניתן להבטיח טוב יותר שהנתונים לא ישותפו בטעות עם אפליקציות לא מורשות או לא ישותפו איתם באופן מכוון. מנהלי IT יכולים גם למחוק באופן סלקטיבי נתונים ארגוניים, בנפרד מהקבצים של המשתמש, אם הם עוזבים את הארגון.
ניהול מכשירים בבעלות החברה
אפשר להשתמש במכשירי Android בבעלות החברה על ידי פריסת המכשירים במצב מכשיר מנוהל. המכשיר המנוהל נרשם באמצעות ספק EMM, שיכול לספק ניהול מלא של מחזור החיים באמצעות מכשיר Android והנתונים שלו. הפעולות האלה כוללות נעילה של תכונות חומרה, הגנה מפני איפוס להגדרות המקוריות וביטול הרשמה, מחיקה ואיפוס מרחוק של המכשיר כולו והתאמת אישית של אפליקציות, כולל תמיכה בפריסות של אפליקציות "קיוסק" או "אפליקציות בודדות". באופן כללי, ארגונים שמשתמשים במצב מכשיר מנוהל ינהלו לפחות סוג אחד מתוך שלושה סוגי פריסות, אבל ניתן לשלב ביניהם ולהתאים אותם לכל אורך הצי של הארגון, בהתאם לדרישות שלהם:
- עבודה בלבד: בדרך כלל פריסות מסוג 'עבודה בלבד' מטרגטות עובדים שמשתמשים במכשיר למגוון אפליקציות. שימוש אישי לא נתמך בשיטה הזו.
- הפעלה אישית: פריסות שמופעלות באופן אישי מטרגטות בדרך כלל עובדים שהמעסיק שלהם סיפק להם מכשיר, אבל הם רוצים שתהיה להם גמישות להשתמש גם באפליקציות אישיות במכשיר. הפריסה של פרופיל העבודה במכשיר מנוהל מאפשרת לעובדים להריץ אפליקציות עבודה לצד אפליקציות אישיות, בלי לפגוע בנתונים של הארגון.
- מכשיר ייעודי: פריסות של מכשירים ייעודיים כוללות בדרך כלל מכשירים מנוהלים, שלפעמים נקראים 'בבעלות חברה, שימוש יחיד' או 'COSU', ונועלים את החומרה והאפליקציות כדי להתאים את המכשיר לפונקציות העבודה הספציפיות שהעובדים צריכים לבצע.
מומלץ לפרוס מכשירים בבעלות החברה כמכשיר מנוהל, כי זה מאפשר לנהל את כל מחזור החיים של המכשיר, כולל איפוס מלא של המכשיר ומדיניות ההגנה מפני איפוס להגדרות המקוריות.
הנחיות ללקוחות בנושא העברה
BYOD: אדמין במכשיר לפריסות של פרופיל עבודה
מומלץ להשתמש בפרופילי עבודה בכל המכשירים שבבעלות אדם פרטי. אפשר לטפל בהעברה מאדמין של מכשיר מדור קודם לפרופיל עבודה עם הפרעה מינימלית. אפשר לטפל בתופעה הזו על ידי דחיפת מכשירים אישיים להתקנת פרופיל עבודה, או על ידי הרשמה של מכשירים חדשים באמצעות פרופיל עבודה בזמן שמכשירים קיימים יוצאים מהצי.
מכשירים בבעלות החברה: ניהול המכשיר ברמת המכשיר המנוהל
מומלץ להגדיר מכשירים בבעלות החברה כמכשירים מנוהלים באופן מלא. כדי להעביר מכשיר מאדמין המכשיר למכשיר מנוהל, צריך לאפס אותו להגדרות המקוריות. מכיוון שהדבר מפריע יותר למשתמשים, אנחנו ממליצים לבצע הטמעה הדרגתית, לפיה מכשירים חדשים רשומים כמכשירים מנוהלים אבל מכשירים קיימים נשארים בניהול המכשיר.
סוגי מיגרציה
כמה אסטרטגיות העברה כלליות מוגדרות בקצרה כך:
Big bang: אוכלוסיות גדולות של משתמשים קיימים מתבקשים לשדרג למכשיר מנוהל או לפרופיל עבודה במסגרת שדרוג אחד או יותר.
הטמעה הדרגתית: מצבי הניהול החדשים מוגדרים למשתמשים חדשים ולמכשירים חדשים מיד כשהם נרשמים. מכשירים ישנים יותר של מנהלי מכשירים מיושנים שלא בצי, על ידי שחיקה טבעית.
שאלות נפוצות
מה לגבי מכשירים ישנים יותר?
לאחר ההשקה של גרסת Android 10.0, אנחנו מצפים שכל המכשירים שתומכים בה יתמכו במצב של מכשיר מנוהל או של פרופיל עבודה. אפשר להעביר מכשירים ישנים יותר כפי שמתואר למעלה או לנהל אותם באמצעות ניהול המכשיר עד שמחליפים אותם.
מה קורה אם יש אפליקציות שלא סופקו לניהול הניידות בארגון?
לפעמים, אפליקציות כמו אפליקציית אימייל יכולות להפוך לאדמין מכשיר בתגובה למדיניות ארגונית שנאכפת על שרתי אימייל. החל מההשקה של Android 10.0, האפליקציות האלה יהיו כפופות לאותן הגבלות: הן יכולות להפוך לאדמינים של מכשירים, אבל לא יכולים לאכוף כללי מדיניות לסיסמאות או הגבלות חומרה. בהתאם לתרחיש השימוש, האפליקציות האלה יכולות:
- לעצב פרופיל עבודה בעצמם (להפוך לבקר DPC).
- מבקשים מהמשתמשים להגדיר את האפליקציה ב-EMM אחר (בשליטה של DPC אחר אם יש צורך).
- לבחור אם להטמיע הגבלות משלהם לסיסמאות (באפליקציה).
מומלץ להגדיר באפליקציות האלה מנגנון לזיהוי אם המכשיר מנוהל על ידי ספק EMM, ולהיעזר בו לניהול של ספק ה-EMM. הזיהוי הזה מתבצע על ידי המרת אסימונים באמצעות ניהול הגדרות בנייד (MCM).
מה קורה כשגרסת Android 10.0 הושקה?
ההתנהגויות שהוצאו משימוש יפסיקו לפעול ויחזירו חריג אבטחה לאפליקציות עם Android 10.0 שמטרגטות לרמת API זו.