1. Zen IT Technologies
  2. ניהול תחנות קצה ו-MDM

כל מחשב מנוהל ומתועד, מרגע הרכישה ועד היציאה משימוש.

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

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

בואו נדבר

הבעיה

על צי שאף אחד לא תכנן, אף אחד לא יכול לתת תשובות.

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

  • הכנת מחשבים ידנית.

    כל הכנה נשענת על כך שאיש IT אחד זוכר כל שלב, ומייצרת מכשיר שקצת שונה מכל השאר.

  • הצפנה שמניחים שהיא פעילה.

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

  • המכשירים יוצאים בהדרגה מהתצורה שהוגדרה.

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

  • מלאי שכבר לא משקף את המציאות.

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

  • מחשב נעלם. מה בעצם אפשר לעשות?

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

מה כולל ניהול תחנות קצה

  1. קליטה
  2. רישום אוטומטי
  3. מכשיר מנוהל
  4. עדכונים וקו בסיס אבטחה
  5. מחיקה מאובטחת
  • רישום והגדרה

    מכשיר חדש אמור להגיע למצב שהוגדר לו בלי שמישהו יעבור ידנית על רשימת פעולות. אנחנו מבצעים אוטומציה של הרישום וההגדרה ב-macOS, ב-Windows וב-Linux בהתאם ליכולות של כל פלטפורמה, על פלטפורמת הניהול שמתאימה לסביבה, ומשתמשים ב-zero-touch במקום שבו המכשיר ופלטפורמת הניהול תומכים בכך. מחשבי Apple שבבעלות החברה נרשמים דרך הארגון, כך שהניהול והיכולת לשחזר אותם נשארים בשליטת החברה. הצפנה, סוכני אבטחה, הגדרות זהות והתוכנות שהעובד צריך מוחלים דרך מדיניות, כך שהמחשב המאה מוגדר בדיוק כמו הראשון.

  • אבטחה ותחזוקה שוטפת

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

  • זיהוי ותגובה

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

  • מעקב ובקרה

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

  • סיום מחזור החיים

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

הרשאות מקומיות לפי תפקיד

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

גישה מותנית ואמון במכשיר

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

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

מחזור החיים של המכשיר לא נגמר ב-MDM

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

מחשב שחוזר עדיין צריך להפוך למלאי שמיש. מחשב Mac בבעלות החברה שמשויך ל-Apple Account הפרטי של העובד יכול לחזור פיזית ועדיין להיות נעול ב-Activation Lock, אם הקשר הזה לא נוהל כראוי. רישום הנכסים צריך להבחין בין מכשיר שהוחזר, מכשיר שממתין לטיפול ומכשיר שמוכן לשימוש חוזר, כך שצוות התפעול רואה את המלאי הזמין וצוות הכספים רואה איזה ציוד מתקרב להחלפה.

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

מסמכים טכניים באנגלית

מה באמת נדרש להקמה אוטומטית של מכשירים

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

עוד בנושא

איך זה עובד

  1. מיפוי.

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

  2. תכנון.

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

  3. פריסה.

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

  4. תחזוקה.

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

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

זמין כפרויקט ←

דוגמאות מהשטח

  • צי מכשירים רב-פלטפורמי עבר לפריסה ללא מגע.

    חברת טכנולוגיה

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

  • הכנת מחשבים ידנית הוסרה מתהליך הקליטה.

    חברת טכנולוגיה

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

  • מעבר בין פלטפורמות ניהול תוך שמירה על הרישום.

    חברת טכנולוגיה

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

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

למי זה מתאים

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

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

שאלות נפוצות

  • אם כבר יש לנו EDR, צריך גם MDM?

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

  • אתם יכולים לנהל Linux לצד macOS ו-Windows?

    כן. בסביבות מעורבות משתמשים לא פעם בפלטפורמות כמו Jamf, Iru, Mosyle, JumpCloud או Intune, ורמת הניהול שכל אחת מהן מספקת משתנה בין מערכות ההפעלה. Linux הוא לעיתים המקום שבו הפערים מתגלים, ולכן אנחנו מתכננים עבורו מראש ולא מתייחסים אליו כחריג.

  • מה קורה למכשיר כשעובד עוזב?

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

  • עד כמה תהליך הרישום מפריע כשצי המכשירים כבר נמצא בשטח?

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

  • ומה לגבי מכשירים פרטיים?

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

  • האם אתם מספקים שירותי הקצאת ציוד ו-White Glove גם מחוץ לישראל?

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

    בהתאם לסביבה, ניתן לרכוש מכשירי Apple דרך Apple או ספקים מורשים ולשייך אותם ל-Apple Business Manager. בסביבות Windows ניתן להשתמש באפשרויות הקצאה והכנה מצד היצרן, כגון Windows Autopilot ושירותי ההכנה של Dell, כולל Dell Image Assist כאשר הם מתאימים, כך שהמכשירים יכולים להגיע מוכנים למודל ההקצאה של הלקוח. בסביבות שבהן משתמשים במספר סוגי ציוד, אנחנו יכולים לעבוד גם עם ספקים מוכרים שתומכים במספר יצרנים ובאספקה בינלאומית.

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

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