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

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

למה גישת ספקים הופכת במהירות לסיכון

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

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

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

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

מודל יעיל נשען על חמישה כללים מעשיים:

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

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

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

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

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

מיפוי הנתיבים שקיימים כבר עכשיו

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

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

חיבור מרחוק אינו אישור לגישה בלתי מוגבלת

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

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

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

ניהול סודות וסיסמאות: הבעיה שאסור להשאיר בצ'אט

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

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

בקרה שוטפת: מה לבדוק ולא רק מה להגדיר

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

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

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

מה עושים כשספק מדווח על אירוע

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

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

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