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

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

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

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

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

ניהול הרשאות לספקים חיצוניים: 5 כללי ברזל

1. זהות אישית לכל איש קשר, לעולם לא חשבון משותף

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

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

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

2. גישה מינימלית, למערכת מוגדרת ולחלון זמן מוגדר

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

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

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

3. MFA הוא תנאי כניסה, לא שכבת הגנה אופציונלית

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

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

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

4. תעדו ונטרו את המפגש, לא רק את ההתחברות

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

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

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

5. הגדירו בעלות, אישור תקופתי ותהליך יציאה

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

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

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

תהליך קצר שעובד גם תחת לחץ

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

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

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

טעויות שכדאי לעצור לפני הביקורת הבאה

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

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

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