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

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

למה חשבונות ספקים הופכים לסיכון מצטבר

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

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

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

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

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

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

זהות אישית, לא משתמש משותף

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

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

MFA הוא תנאי בסיס, לא פיצ'ר מתקדם

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

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

תוקף אוטומטי עדיף על תזכורת ידנית

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

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

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

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

תהליך יעיל כולל חמישה שלבים מובחנים:

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

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

בחירת ערוץ הגישה משנה את רמת הסיכון

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

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

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

ביקורת, לוגים ואחריות לאורך חיי ההרשאה

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

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

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

החיבור בין אבטחה, רישוי ו-FinOps

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

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

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

טעויות שחוזרות על עצמן

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

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

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

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