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

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

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

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

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

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

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

מקרה בוחן מעבר לניהול ענן: לא מתחילים בהעברה

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

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

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

מה השתנה בתהליך ההצטרפות והעזיבה

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

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

גישה מרחוק: פחות חריגים, יותר בקרה

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

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

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

רישוי ו-FinOps: המספרים מתחילים לדבר

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

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

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

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

מה לא עבד בדרך

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

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

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

התוצאה: צוות IT שמנהל חריגים במקום לרדוף אחריהם

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

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

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